[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120915173752.GA10698@stainedmachine.redhat.com>
Date: Sat, 15 Sep 2012 19:37:53 +0200
From: Petr Holasek <pholasek@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Chris Wright <chrisw@...s-sol.org>,
Izik Eidus <izik.eidus@...ellosystems.com>,
Rik van Riel <riel@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Anton Arapov <anton@...hat.com>
Subject: Re: [PATCH v3] KSM: numa awareness sysfs knob
On Fri, 14 Sep 2012, Andrew Morton wrote:
Hi Andrew,
at first thanks for your review!
> On Fri, 14 Sep 2012 23:22:47 +0200
> Petr Holasek <pholasek@...hat.com> wrote:
>
> > Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_nodes
>
> I wonder if merge_across_nodes would be a better name.
>
Agreed.
> > which control merging pages across different numa nodes.
> > When it is set to zero only pages from the same node are merged,
> > otherwise pages from all nodes can be merged together (default behavior).
> >
> > Typical use-case could be a lot of KVM guests on NUMA machine
> > and cpus from more distant nodes would have significant increase
> > of access latency to the merged ksm page. Sysfs knob was choosen
> > for higher scalability.
>
> Well... what is the use case for merge_nodes=0? IOW, why shouldn't we
> make this change non-optional and avoid the sysfs knob?
I assume that there are still some users who want to use KSM mainly for
saving of physical memory and access latency is not priority for them.
> >
> > This patch also adds share_all sysfs knob which can be used for adding
> > all anon vmas of all processes in system to ksmd scan queue. Knob can be
> > triggered only when run knob is set to zero.
>
> I really don't understand this share_all thing. From reading the code,
> it is a once-off self-resetting trigger thing. Why? How is one to use
> this? What's the benefit? What's the effect?
I introduced it on the basis of our discussion about v2 patch
https://lkml.org/lkml/2012/6/29/426 as some knob which can madvise all anon
mappings with MADV_MERGEABLE. But I might have misunderstood your idea.
If you don't like current self-resetting trigger we either can implement it
as stable 0/1 knob that would madvise all current and future anon mappings
when set to 1 or completely exclude this share_all thing from the patch.
I am going to fix all all mistakes you pointed out in your review as well as
add more verbose documentation and comments in next version.
thanks,
Petr H
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists