Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Mon, 7 Jan 2013, Simon Jeons wrote: > On Thu, 2013-01-03 at 13:24 +0100, Petr Holasek wrote: > > Hi Simon, > > > > On Mon, 31 Dec 2012, Simon Jeons wrote: > > > On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote: > > > > > > > > v7: - added sysfs ABI documentation for KSM > > > > > > Hi Petr, > > > > > > How you handle "memory corruption because the ksm page still points to > > > the stable_node that has been freed" mentioned by Andrea this time? > > > > > > > Hi Petr, > > You still didn't answer my question mentioned above. :) Yes, I noticed that too :) I think Petr probably hopes that I'll answer; and yes, I do hold myself responsible for solving this. The honest answer is that I forgot all about it for a while. I had to go back to read the various threads to remind myself of what Andrea said back then, and the ideas I had in replying. Thank you for reminding us. I do intend to fix it along the lines I suggested then, if that works out; but that is a danger in memory hotremove only, so at present I'm still wrestling with the more immediate problem of stale stable_nodes when switching merge_across_nodes between 1 and 0 and 1. Many of the problems there come from reclaim under memory pressure: stable pages being written out to swap, and faulted back in at "the wrong time". Essentially, existing bugs in KSM_RUN_UNMERGE, that were not visible until merge_across_nodes brought us to rely upon it. I have "advanced" from kernel oopses to userspace corruption: that's no advance at all, no doubt I'm doing something stupid, but I haven't spotted it yet; and once I've fixed that up, shall probably want to look back at the little heap of fixups (a remove_all_stable_nodes() function) and go about it quite differently - but for now I'm still learning from the bugs I give myself. > > > > > > > > > > > > > + /* > > > > +* If tree_page has been migrated to another NUMA node, > > > > it > > > > +* will be flushed out and put into the right unstable > > > > tree > > > > +* next time: only merge with it if merge_across_nodes. > > > > > > Why? Do you mean swap based migration? Or where I miss ? > > > > > > > It can be physical page migration triggered by page compaction, memory > > hotplug > > or some NUMA sched/memory balancing algorithm developed recently. > > > > > > +* Just notice, we don't have similar problem for > > > > PageKsm > > > > +* because their migration is disabled now. (62b61f611e) > > > > +*/ > > > > Migration of KSM pages is disabled now, you can look into ^^^ commit and > > changes introduced to migrate.c. Migration of KSM pages is still enabled in the memory hotremove case. I don't remember how I tested that back then, so I want to enable KSM page migration generally, just to be able to test it more thoroughly. That would then benefit compaction, no longer frustrated by a KSM page in the way. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Thu, 2013-01-03 at 13:24 +0100, Petr Holasek wrote:
> Hi Simon,
>
> On Mon, 31 Dec 2012, Simon Jeons wrote:
> > On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
> > >
> > > v7: - added sysfs ABI documentation for KSM
> >
> > Hi Petr,
> >
> > How you handle "memory corruption because the ksm page still points to
> > the stable_node that has been freed" mentioned by Andrea this time?
> >
>
Hi Petr,
You still didn't answer my question mentioned above. :)
>
>
> > >
> > > + /*
> > > + * If tree_page has been migrated to another NUMA node, it
> > > + * will be flushed out and put into the right unstable tree
> > > + * next time: only merge with it if merge_across_nodes.
> >
> > Why? Do you mean swap based migration? Or where I miss ?
> >
>
> It can be physical page migration triggered by page compaction, memory hotplug
> or some NUMA sched/memory balancing algorithm developed recently.
>
> > > + * Just notice, we don't have similar problem for PageKsm
> > > + * because their migration is disabled now. (62b61f611e)
> > > + */
>
> Migration of KSM pages is disabled now, you can look into ^^^ commit and
> changes introduced to migrate.c.
>
> > > + if (!ksm_merge_across_nodes && page_to_nid(tree_page) != nid) {
> > > + put_page(tree_page);
> > > + return NULL;
> > > + }
> > > +
> > > ret = memcmp_pages(page, tree_page);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Fri, 2013-01-04 at 15:03 -0800, Hugh Dickins wrote: > On Thu, 3 Jan 2013, Simon Jeons wrote: > > On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote: > > > > > > As you can see, remove_rmap_item_from_tree uses it to decide whether > > > or not it should rb_erase the rmap_item from the unstable_tree. > > > > > > Every full scan of all the rmap_items, we increment ksm_scan.seqnr, > > > forget the old unstable_tree (it would just be a waste of processing > > > to remove every node one by one), and build up the unstable_tree afresh. > > > > > > > When the rmap_items left over from the previous scan will be removed? > > Removed from the unstable rbtree? Not at all, it's simply restarted > afresh, and the old rblinkages ignored. Freed back to slab? When the > scan passes that mm+address and realizes that rmap_item is not wanted > any more. (Or when ksm is shut down with KSM_RUN_UNMERGE.) > Make sense. Thanks Hugh. :) > > > > > That works fine until we need to remove an rmap_item: then we have to be > > > very sure to remove it from the unstable_tree if it's already been linked > > > there during this scan, but ignore its rblinkage if that's just left over > > > from the previous scan. > > > > > > A single bit would be enough to decide this; but we got it troublesomely > > > wrong in the early days of KSM (didn't always visit every rmap_item each > > > scan), so it's convenient to use 8 bits (the low unsigned char, stored > > > > When the scenario didn't always visit every rmap_item each scan can > > occur? > > You're asking me about a stage of KSM development 3.5 years ago: > I don't remember the details. > > > > > > below the FLAGs and below the page-aligned address in the rmap_item - > > > there's lots of them, best keep them as small as we can) and do a > > > BUG_ON(age > 1) if we made a mistake. > > > > > > We haven't hit that BUG_ON in over three years: if we need some more > > > bits for something, we can cut the age down to one or two bits. > > > > > > Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Thu, 3 Jan 2013, Simon Jeons wrote: > On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote: > > > > As you can see, remove_rmap_item_from_tree uses it to decide whether > > or not it should rb_erase the rmap_item from the unstable_tree. > > > > Every full scan of all the rmap_items, we increment ksm_scan.seqnr, > > forget the old unstable_tree (it would just be a waste of processing > > to remove every node one by one), and build up the unstable_tree afresh. > > > > When the rmap_items left over from the previous scan will be removed? Removed from the unstable rbtree? Not at all, it's simply restarted afresh, and the old rblinkages ignored. Freed back to slab? When the scan passes that mm+address and realizes that rmap_item is not wanted any more. (Or when ksm is shut down with KSM_RUN_UNMERGE.) > > > That works fine until we need to remove an rmap_item: then we have to be > > very sure to remove it from the unstable_tree if it's already been linked > > there during this scan, but ignore its rblinkage if that's just left over > > from the previous scan. > > > > A single bit would be enough to decide this; but we got it troublesomely > > wrong in the early days of KSM (didn't always visit every rmap_item each > > scan), so it's convenient to use 8 bits (the low unsigned char, stored > > When the scenario didn't always visit every rmap_item each scan can > occur? You're asking me about a stage of KSM development 3.5 years ago: I don't remember the details. > > > below the FLAGs and below the page-aligned address in the rmap_item - > > there's lots of them, best keep them as small as we can) and do a > > BUG_ON(age > 1) if we made a mistake. > > > > We haven't hit that BUG_ON in over three years: if we need some more > > bits for something, we can cut the age down to one or two bits. > > > > Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote: > On Tue, 1 Jan 2013, Simon Jeons wrote: > > > > Hi Petr and Hugh, > > > > One offline question, thanks for your clarify. > > Perhaps not as offline as you intended :) Hi Hugh, Thanks for your detail explanation. :) > > > > > How to understand age = (unsigned char)(ksm_scan.seqnr - > > rmap_item->address);? It used for what? > > As you can see, remove_rmap_item_from_tree uses it to decide whether > or not it should rb_erase the rmap_item from the unstable_tree. > > Every full scan of all the rmap_items, we increment ksm_scan.seqnr, > forget the old unstable_tree (it would just be a waste of processing > to remove every node one by one), and build up the unstable_tree afresh. > When the rmap_items left over from the previous scan will be removed? > That works fine until we need to remove an rmap_item: then we have to be > very sure to remove it from the unstable_tree if it's already been linked > there during this scan, but ignore its rblinkage if that's just left over > from the previous scan. > > A single bit would be enough to decide this; but we got it troublesomely > wrong in the early days of KSM (didn't always visit every rmap_item each > scan), so it's convenient to use 8 bits (the low unsigned char, stored When the scenario didn't always visit every rmap_item each scan can occur? > below the FLAGs and below the page-aligned address in the rmap_item - > there's lots of them, best keep them as small as we can) and do a > BUG_ON(age > 1) if we made a mistake. > > We haven't hit that BUG_ON in over three years: if we need some more > bits for something, we can cut the age down to one or two bits. > > Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
Hi Simon,
On Mon, 31 Dec 2012, Simon Jeons wrote:
> On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
> >
> > v7: - added sysfs ABI documentation for KSM
>
> Hi Petr,
>
> How you handle "memory corruption because the ksm page still points to
> the stable_node that has been freed" mentioned by Andrea this time?
>
> >
> > + /*
> > +* If tree_page has been migrated to another NUMA node, it
> > +* will be flushed out and put into the right unstable tree
> > +* next time: only merge with it if merge_across_nodes.
>
> Why? Do you mean swap based migration? Or where I miss ?
>
It can be physical page migration triggered by page compaction, memory hotplug
or some NUMA sched/memory balancing algorithm developed recently.
> > +* Just notice, we don't have similar problem for PageKsm
> > +* because their migration is disabled now. (62b61f611e)
> > +*/
Migration of KSM pages is disabled now, you can look into ^^^ commit and
changes introduced to migrate.c.
> > + if (!ksm_merge_across_nodes && page_to_nid(tree_page) != nid) {
> > + put_page(tree_page);
> > + return NULL;
> > + }
> > +
> > ret = memcmp_pages(page, tree_page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Tue, 1 Jan 2013, Simon Jeons wrote: > > Hi Petr and Hugh, > > One offline question, thanks for your clarify. Perhaps not as offline as you intended :) > > How to understand age = (unsigned char)(ksm_scan.seqnr - > rmap_item->address);? It used for what? As you can see, remove_rmap_item_from_tree uses it to decide whether or not it should rb_erase the rmap_item from the unstable_tree. Every full scan of all the rmap_items, we increment ksm_scan.seqnr, forget the old unstable_tree (it would just be a waste of processing to remove every node one by one), and build up the unstable_tree afresh. That works fine until we need to remove an rmap_item: then we have to be very sure to remove it from the unstable_tree if it's already been linked there during this scan, but ignore its rblinkage if that's just left over from the previous scan. A single bit would be enough to decide this; but we got it troublesomely wrong in the early days of KSM (didn't always visit every rmap_item each scan), so it's convenient to use 8 bits (the low unsigned char, stored below the FLAGs and below the page-aligned address in the rmap_item - there's lots of them, best keep them as small as we can) and do a BUG_ON(age > 1) if we made a mistake. We haven't hit that BUG_ON in over three years: if we need some more bits for something, we can cut the age down to one or two bits. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
> Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
> 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 variability when some users still prefers higher amount
> of saved physical memory regardless of access latency.
>
> Every numa node has its own stable & unstable trees because of faster
> searching and inserting. Changing of merge_across_nodes value is possible
> only when there are not any ksm shared pages in system.
>
> I've tested this patch on numa machines with 2, 4 and 8 nodes and
> measured speed of memory access inside of KVM guests with memory pinned
> to one of nodes with this benchmark:
>
> http://pholasek.fedorapeople.org/alloc_pg.c
>
> Population standard deviations of access times in percentage of average
> were following:
>
> merge_across_nodes=1
> 2 nodes 1.4%
> 4 nodes 1.6%
> 8 nodes 1.7%
>
> merge_across_nodes=0
> 2 nodes 1%
> 4 nodes 0.32%
> 8 nodes 0.018%
>
> RFC: https://lkml.org/lkml/2011/11/30/91
> v1: https://lkml.org/lkml/2012/1/23/46
> v2: https://lkml.org/lkml/2012/6/29/105
> v3: https://lkml.org/lkml/2012/9/14/550
> v4: https://lkml.org/lkml/2012/9/23/137
> v5: https://lkml.org/lkml/2012/12/10/540
> v6: https://lkml.org/lkml/2012/12/23/154
>
> Changelog:
>
> v2: Andrew's objections were reflected:
> - value of merge_nodes can't be changed while there are some ksm
> pages in system
> - merge_nodes sysfs entry appearance depends on CONFIG_NUMA
> - more verbose documentation
> - added some performance testing results
>
> v3: - more verbose documentation
> - fixed race in merge_nodes store function
> - introduced share_all debugging knob proposed by Andrew
> - minor cleanups
>
> v4: - merge_nodes was renamed to merge_across_nodes
> - share_all debug knob was dropped
> - get_kpfn_nid helper
> - fixed page migration behaviour
>
> v5: - unstable node's nid presence depends on CONFIG_NUMA
> - fixed oops appearing when stable nodes were removed from tree
> - roots of stable trees are initialized properly
> - fixed unstable page migration issue
>
> v6: - fixed oops caused by stable_nodes appended to wrong tree
> - KSM_RUN_MERGE test removed
>
> v7: - added sysfs ABI documentation for KSM
>
> Signed-off-by: Petr Holasek
> Signed-off-by: Hugh Dickins
> Acked-by: Rik van Riel
> ---
> Documentation/vm/ksm.txt | 7 +++
> mm/ksm.c | 151
> +--
> 2 files changed, 139 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
> index b392e49..25cc89b 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,13 @@ sleep_millisecs - how many milliseconds ksmd should sleep
> before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>
> +merge_across_nodes - specifies if pages from different numa nodes can be
> merged.
> + When set to 0, ksm merges only pages which physically
> + reside in the memory area of same NUMA node. It brings
> + lower latency to access to shared page. Value can be
> + changed only when there is no ksm shared pages in system.
> + Default: 1
> +
> run - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 5157385..d1e1041 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "internal.h"
> @@ -139,6 +140,9 @@ struct rmap_item {
> struct mm_struct *mm;
> unsigned long address; /* + low bits used for flags below */
> unsigned int oldchecksum; /* when unstable */
> +#ifdef CONFIG_NUMA
> + unsigned int nid;
> +#endif
> union {
> struct rb_node node;/* when node of unstable tree */
> struct {/* when listed from stable tree */
> @@ -153,8 +157,8 @@ struct rmap_item {
> #define STABLE_FLAG 0x200 /* is listed from the stable tree */
>
> /* The stable and unstable tree heads */
> -static struct rb_root root_stable_tree = RB_ROOT;
> -static struct rb_root root_unstable_tree = RB_ROOT;
>
Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Fri, 2012-12-28 at 02:32 +0100, Petr Holasek wrote:
> Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
> 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 variability when some users still prefers higher amount
> of saved physical memory regardless of access latency.
>
> Every numa node has its own stable & unstable trees because of faster
> searching and inserting. Changing of merge_across_nodes value is possible
> only when there are not any ksm shared pages in system.
>
> I've tested this patch on numa machines with 2, 4 and 8 nodes and
> measured speed of memory access inside of KVM guests with memory pinned
> to one of nodes with this benchmark:
>
> http://pholasek.fedorapeople.org/alloc_pg.c
>
> Population standard deviations of access times in percentage of average
> were following:
>
> merge_across_nodes=1
> 2 nodes 1.4%
> 4 nodes 1.6%
> 8 nodes 1.7%
>
> merge_across_nodes=0
> 2 nodes 1%
> 4 nodes 0.32%
> 8 nodes 0.018%
>
> RFC: https://lkml.org/lkml/2011/11/30/91
> v1: https://lkml.org/lkml/2012/1/23/46
> v2: https://lkml.org/lkml/2012/6/29/105
> v3: https://lkml.org/lkml/2012/9/14/550
> v4: https://lkml.org/lkml/2012/9/23/137
> v5: https://lkml.org/lkml/2012/12/10/540
> v6: https://lkml.org/lkml/2012/12/23/154
>
> Changelog:
>
> v2: Andrew's objections were reflected:
> - value of merge_nodes can't be changed while there are some ksm
> pages in system
> - merge_nodes sysfs entry appearance depends on CONFIG_NUMA
> - more verbose documentation
> - added some performance testing results
>
> v3: - more verbose documentation
> - fixed race in merge_nodes store function
> - introduced share_all debugging knob proposed by Andrew
> - minor cleanups
>
> v4: - merge_nodes was renamed to merge_across_nodes
> - share_all debug knob was dropped
> - get_kpfn_nid helper
> - fixed page migration behaviour
>
> v5: - unstable node's nid presence depends on CONFIG_NUMA
> - fixed oops appearing when stable nodes were removed from tree
> - roots of stable trees are initialized properly
> - fixed unstable page migration issue
>
> v6: - fixed oops caused by stable_nodes appended to wrong tree
> - KSM_RUN_MERGE test removed
>
> v7: - added sysfs ABI documentation for KSM
Hi Petr,
How you handle "memory corruption because the ksm page still points to
the stable_node that has been freed" mentioned by Andrea this time?
>
> Signed-off-by: Petr Holasek
> Signed-off-by: Hugh Dickins
> Acked-by: Rik van Riel
> ---
> Documentation/vm/ksm.txt | 7 +++
> mm/ksm.c | 151
> +--
> 2 files changed, 139 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
> index b392e49..25cc89b 100644
> --- a/Documentation/vm/ksm.txt
> +++ b/Documentation/vm/ksm.txt
> @@ -58,6 +58,13 @@ sleep_millisecs - how many milliseconds ksmd should sleep
> before next scan
> e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
> Default: 20 (chosen for demonstration purposes)
>
> +merge_across_nodes - specifies if pages from different numa nodes can be
> merged.
> + When set to 0, ksm merges only pages which physically
> + reside in the memory area of same NUMA node. It brings
> + lower latency to access to shared page. Value can be
> + changed only when there is no ksm shared pages in system.
> + Default: 1
> +
> run - set 0 to stop ksmd from running but keep merged pages,
> set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
> set 2 to stop ksmd and unmerge all pages currently merged,
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 5157385..d1e1041 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include "internal.h"
> @@ -139,6 +140,9 @@ struct rmap_item {
> struct mm_struct *mm;
> unsigned long address; /* + low bits used for flags below */
> unsigned int oldchecksum; /* when unstable */
> +#ifdef CONFIG_NUMA
> + unsigned int nid;
> +#endif
> union {
> struct rb_node node;/* when node of unstable tree */
> struct {/* when listed from stable tree */
> @@ -153,8 +157,8 @@ struct rmap_item {
> #define STABLE_FLAG 0x200 /* is listed from the stable tree */
>
>
[PATCH v7 1/2] KSM: numa awareness sysfs knob
Introduces new sysfs boolean knob /sys/kernel/mm/ksm/merge_across_nodes
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 variability when some users still prefers higher amount
of saved physical memory regardless of access latency.
Every numa node has its own stable & unstable trees because of faster
searching and inserting. Changing of merge_across_nodes value is possible
only when there are not any ksm shared pages in system.
I've tested this patch on numa machines with 2, 4 and 8 nodes and
measured speed of memory access inside of KVM guests with memory pinned
to one of nodes with this benchmark:
http://pholasek.fedorapeople.org/alloc_pg.c
Population standard deviations of access times in percentage of average
were following:
merge_across_nodes=1
2 nodes 1.4%
4 nodes 1.6%
8 nodes 1.7%
merge_across_nodes=0
2 nodes 1%
4 nodes 0.32%
8 nodes 0.018%
RFC: https://lkml.org/lkml/2011/11/30/91
v1: https://lkml.org/lkml/2012/1/23/46
v2: https://lkml.org/lkml/2012/6/29/105
v3: https://lkml.org/lkml/2012/9/14/550
v4: https://lkml.org/lkml/2012/9/23/137
v5: https://lkml.org/lkml/2012/12/10/540
v6: https://lkml.org/lkml/2012/12/23/154
Changelog:
v2: Andrew's objections were reflected:
- value of merge_nodes can't be changed while there are some ksm
pages in system
- merge_nodes sysfs entry appearance depends on CONFIG_NUMA
- more verbose documentation
- added some performance testing results
v3: - more verbose documentation
- fixed race in merge_nodes store function
- introduced share_all debugging knob proposed by Andrew
- minor cleanups
v4: - merge_nodes was renamed to merge_across_nodes
- share_all debug knob was dropped
- get_kpfn_nid helper
- fixed page migration behaviour
v5: - unstable node's nid presence depends on CONFIG_NUMA
- fixed oops appearing when stable nodes were removed from tree
- roots of stable trees are initialized properly
- fixed unstable page migration issue
v6: - fixed oops caused by stable_nodes appended to wrong tree
- KSM_RUN_MERGE test removed
v7: - added sysfs ABI documentation for KSM
Signed-off-by: Petr Holasek
Signed-off-by: Hugh Dickins
Acked-by: Rik van Riel
---
Documentation/vm/ksm.txt | 7 +++
mm/ksm.c | 151 +--
2 files changed, 139 insertions(+), 19 deletions(-)
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index b392e49..25cc89b 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -58,6 +58,13 @@ sleep_millisecs - how many milliseconds ksmd should sleep
before next scan
e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
Default: 20 (chosen for demonstration purposes)
+merge_across_nodes - specifies if pages from different numa nodes can be
merged.
+ When set to 0, ksm merges only pages which physically
+ reside in the memory area of same NUMA node. It brings
+ lower latency to access to shared page. Value can be
+ changed only when there is no ksm shared pages in system.
+ Default: 1
+
run - set 0 to stop ksmd from running but keep merged pages,
set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
set 2 to stop ksmd and unmerge all pages currently merged,
diff --git a/mm/ksm.c b/mm/ksm.c
index 5157385..d1e1041 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -139,6 +140,9 @@ struct rmap_item {
struct mm_struct *mm;
unsigned long address; /* + low bits used for flags below */
unsigned int oldchecksum; /* when unstable */
+#ifdef CONFIG_NUMA
+ unsigned int nid;
+#endif
union {
struct rb_node node;/* when node of unstable tree */
struct {/* when listed from stable tree */
@@ -153,8 +157,8 @@ struct rmap_item {
#define STABLE_FLAG0x200 /* is listed from the stable tree */
/* The stable and unstable tree heads */
-static struct rb_root root_stable_tree = RB_ROOT;
-static struct rb_root root_unstable_tree = RB_ROOT;
+static struct rb_root root_unstable_tree[MAX_NUMNODES];
+static struct rb_root root_stable_tree[MAX_NUMNODES];
#define MM_SLOTS_HASH_SHIFT 10
#define MM_SLOTS_HASH_HEADS (1 << MM_SLOTS_HASH_SHIFT)
@@ -189,6 +193,9 @@ static unsigned int ksm_thread_pages_to_scan = 100;
/* Mil
