All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Mason <ric.masonn@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>, Petr Holasek <pholasek@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Izik Eidus <izik.eidus@ravellosystems.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/7] ksm: add some comments
Date: Fri, 22 Feb 2013 12:26:08 +0800	[thread overview]
Message-ID: <5126F360.1060507@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1302210018100.17843@eggly.anvils>

On 02/21/2013 04:19 PM, Hugh Dickins wrote:
> Added slightly more detail to the Documentation of merge_across_nodes,
> a few comments in areas indicated by review, and renamed get_ksm_page()'s
> argument from "locked" to "lock_it".  No functional change.
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
> ---
>   Documentation/vm/ksm.txt |   16 ++++++++++++----
>   mm/ksm.c                 |   18 ++++++++++++++----
>   2 files changed, 26 insertions(+), 8 deletions(-)
>
> --- mmotm.orig/Documentation/vm/ksm.txt	2013-02-20 22:28:09.456001057 -0800
> +++ mmotm/Documentation/vm/ksm.txt	2013-02-20 22:28:23.580001392 -0800
> @@ -60,10 +60,18 @@ sleep_millisecs  - how many milliseconds
>   
>   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
> +                   reside in the memory area of same NUMA node. That brings
> +                   lower latency to access of shared pages. Systems with more
> +                   nodes, at significant NUMA distances, are likely to benefit
> +                   from the lower latency of setting 0. Smaller systems, which
> +                   need to minimize memory usage, are likely to benefit from
> +                   the greater sharing of setting 1 (default). You may wish to
> +                   compare how your system performs under each setting, before
> +                   deciding on which to use. merge_across_nodes setting can be
> +                   changed only when there are no ksm shared pages in system:
> +                   set run 2 to unmerge pages first, then to 1 after changing
> +                   merge_across_nodes, to remerge according to the new setting.

What's the root reason merge_across_nodes setting just can be changed 
only when there are no ksm shared pages in system? Can they be unmerged 
and merged again during ksmd scan?

> +                   Default: 1 (merging across nodes as in earlier releases)
>   
>   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",
> --- mmotm.orig/mm/ksm.c	2013-02-20 22:28:09.456001057 -0800
> +++ mmotm/mm/ksm.c	2013-02-20 22:28:23.584001392 -0800
> @@ -87,6 +87,9 @@
>    *    take 10 attempts to find a page in the unstable tree, once it is found,
>    *    it is secured in the stable tree.  (When we scan a new page, we first
>    *    compare it against the stable tree, and then against the unstable tree.)
> + *
> + * If the merge_across_nodes tunable is unset, then KSM maintains multiple
> + * stable trees and multiple unstable trees: one of each for each NUMA node.
>    */
>   
>   /**
> @@ -524,7 +527,7 @@ static void remove_node_from_stable_tree
>    * a page to put something that might look like our key in page->mapping.
>    * is on its way to being freed; but it is an anomaly to bear in mind.
>    */
> -static struct page *get_ksm_page(struct stable_node *stable_node, bool locked)
> +static struct page *get_ksm_page(struct stable_node *stable_node, bool lock_it)
>   {
>   	struct page *page;
>   	void *expected_mapping;
> @@ -573,7 +576,7 @@ again:
>   		goto stale;
>   	}
>   
> -	if (locked) {
> +	if (lock_it) {
>   		lock_page(page);
>   		if (ACCESS_ONCE(page->mapping) != expected_mapping) {
>   			unlock_page(page);
> @@ -703,10 +706,17 @@ static int remove_stable_node(struct sta
>   		return 0;
>   	}
>   
> -	if (WARN_ON_ONCE(page_mapped(page)))
> +	if (WARN_ON_ONCE(page_mapped(page))) {
> +		/*
> +		 * This should not happen: but if it does, just refuse to let
> +		 * merge_across_nodes be switched - there is no need to panic.
> +		 */
>   		err = -EBUSY;
> -	else {
> +	} else {
>   		/*
> +		 * The stable node did not yet appear stale to get_ksm_page(),
> +		 * since that allows for an unmapped ksm page to be recognized
> +		 * right up until it is freed; but the node is safe to remove.
>   		 * This page might be in a pagevec waiting to be freed,
>   		 * or it might be PageSwapCache (perhaps under writeback),
>   		 * or it might have been removed from swapcache a moment ago.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Ric Mason <ric.masonn@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>, Petr Holasek <pholasek@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Izik Eidus <izik.eidus@ravellosystems.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/7] ksm: add some comments
Date: Fri, 22 Feb 2013 12:26:08 +0800	[thread overview]
Message-ID: <5126F360.1060507@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1302210018100.17843@eggly.anvils>

On 02/21/2013 04:19 PM, Hugh Dickins wrote:
> Added slightly more detail to the Documentation of merge_across_nodes,
> a few comments in areas indicated by review, and renamed get_ksm_page()'s
> argument from "locked" to "lock_it".  No functional change.
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
> ---
>   Documentation/vm/ksm.txt |   16 ++++++++++++----
>   mm/ksm.c                 |   18 ++++++++++++++----
>   2 files changed, 26 insertions(+), 8 deletions(-)
>
> --- mmotm.orig/Documentation/vm/ksm.txt	2013-02-20 22:28:09.456001057 -0800
> +++ mmotm/Documentation/vm/ksm.txt	2013-02-20 22:28:23.580001392 -0800
> @@ -60,10 +60,18 @@ sleep_millisecs  - how many milliseconds
>   
>   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
> +                   reside in the memory area of same NUMA node. That brings
> +                   lower latency to access of shared pages. Systems with more
> +                   nodes, at significant NUMA distances, are likely to benefit
> +                   from the lower latency of setting 0. Smaller systems, which
> +                   need to minimize memory usage, are likely to benefit from
> +                   the greater sharing of setting 1 (default). You may wish to
> +                   compare how your system performs under each setting, before
> +                   deciding on which to use. merge_across_nodes setting can be
> +                   changed only when there are no ksm shared pages in system:
> +                   set run 2 to unmerge pages first, then to 1 after changing
> +                   merge_across_nodes, to remerge according to the new setting.

What's the root reason merge_across_nodes setting just can be changed 
only when there are no ksm shared pages in system? Can they be unmerged 
and merged again during ksmd scan?

> +                   Default: 1 (merging across nodes as in earlier releases)
>   
>   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",
> --- mmotm.orig/mm/ksm.c	2013-02-20 22:28:09.456001057 -0800
> +++ mmotm/mm/ksm.c	2013-02-20 22:28:23.584001392 -0800
> @@ -87,6 +87,9 @@
>    *    take 10 attempts to find a page in the unstable tree, once it is found,
>    *    it is secured in the stable tree.  (When we scan a new page, we first
>    *    compare it against the stable tree, and then against the unstable tree.)
> + *
> + * If the merge_across_nodes tunable is unset, then KSM maintains multiple
> + * stable trees and multiple unstable trees: one of each for each NUMA node.
>    */
>   
>   /**
> @@ -524,7 +527,7 @@ static void remove_node_from_stable_tree
>    * a page to put something that might look like our key in page->mapping.
>    * is on its way to being freed; but it is an anomaly to bear in mind.
>    */
> -static struct page *get_ksm_page(struct stable_node *stable_node, bool locked)
> +static struct page *get_ksm_page(struct stable_node *stable_node, bool lock_it)
>   {
>   	struct page *page;
>   	void *expected_mapping;
> @@ -573,7 +576,7 @@ again:
>   		goto stale;
>   	}
>   
> -	if (locked) {
> +	if (lock_it) {
>   		lock_page(page);
>   		if (ACCESS_ONCE(page->mapping) != expected_mapping) {
>   			unlock_page(page);
> @@ -703,10 +706,17 @@ static int remove_stable_node(struct sta
>   		return 0;
>   	}
>   
> -	if (WARN_ON_ONCE(page_mapped(page)))
> +	if (WARN_ON_ONCE(page_mapped(page))) {
> +		/*
> +		 * This should not happen: but if it does, just refuse to let
> +		 * merge_across_nodes be switched - there is no need to panic.
> +		 */
>   		err = -EBUSY;
> -	else {
> +	} else {
>   		/*
> +		 * The stable node did not yet appear stale to get_ksm_page(),
> +		 * since that allows for an unmapped ksm page to be recognized
> +		 * right up until it is freed; but the node is safe to remove.
>   		 * This page might be in a pagevec waiting to be freed,
>   		 * or it might be PageSwapCache (perhaps under writeback),
>   		 * or it might have been removed from swapcache a moment ago.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>


  reply	other threads:[~2013-02-22  4:26 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21  8:17 [PATCH 0/7] ksm: responses to NUMA review Hugh Dickins
2013-02-21  8:17 ` Hugh Dickins
2013-02-21  8:19 ` [PATCH 1/7] ksm: add some comments Hugh Dickins
2013-02-21  8:19   ` Hugh Dickins
2013-02-22  4:26   ` Ric Mason [this message]
2013-02-22  4:26     ` Ric Mason
2013-02-22 20:50     ` Hugh Dickins
2013-02-22 20:50       ` Hugh Dickins
2013-02-21  8:20 ` [PATCH 2/7] ksm: treat unstable nid like in stable tree Hugh Dickins
2013-02-21  8:20   ` Hugh Dickins
2013-02-22  7:13   ` Ric Mason
2013-02-22  7:13     ` Ric Mason
2013-02-22 21:03     ` Hugh Dickins
2013-02-22 21:03       ` Hugh Dickins
2013-03-01  5:29       ` Ric Mason
2013-03-01  5:29         ` Ric Mason
2013-03-01 20:03         ` Hugh Dickins
2013-03-01 20:03           ` Hugh Dickins
2013-03-02  1:10           ` Ric Mason
2013-03-02  1:10             ` Ric Mason
2013-03-02  2:57             ` Hugh Dickins
2013-03-02  2:57               ` Hugh Dickins
2013-03-06  1:28               ` Will Huck
2013-03-06  1:28                 ` Will Huck
2013-03-06  4:31                 ` Hugh Dickins
2013-03-06  4:31                   ` Hugh Dickins
2013-03-06  2:37               ` Ric Mason
2013-03-06  2:37                 ` Ric Mason
2013-03-06  5:05                 ` Hugh Dickins
2013-03-06  5:05                   ` Hugh Dickins
2013-03-06  6:58                   ` Ric Mason
2013-03-06  6:58                     ` Ric Mason
2013-03-06 10:18                   ` Ric Mason
2013-03-06 10:18                     ` Ric Mason
2013-03-07 23:26                     ` Ric Mason
2013-03-07 23:26                       ` Ric Mason
2013-02-21  8:22 ` [PATCH 3/7] ksm: shrink 32-bit rmap_item back to 32 bytes Hugh Dickins
2013-02-21  8:22   ` Hugh Dickins
2013-02-21  8:23 ` [PATCH 4/7] mm,ksm: FOLL_MIGRATION do migration_entry_wait Hugh Dickins
2013-02-21  8:23   ` Hugh Dickins
2013-02-21  8:25 ` [PATCH 5/7] mm,ksm: swapoff might need to copy Hugh Dickins
2013-02-21  8:25   ` Hugh Dickins
2013-02-21 14:53   ` Johannes Weiner
2013-02-21 14:53     ` Johannes Weiner
2013-02-22 17:16     ` Hugh Dickins
2013-02-22 17:16       ` Hugh Dickins
2013-02-21  8:27 ` [PATCH 6/7] mm: cleanup "swapcache" in do_swap_page Hugh Dickins
2013-02-21  8:27   ` Hugh Dickins
2013-02-21  8:29 ` [PATCH 7/7] ksm: allocate roots when needed Hugh Dickins
2013-02-21  8:29   ` Hugh Dickins
2013-02-22  3:44 ` [PATCH 0/7] ksm: responses to NUMA review Ric Mason
2013-02-22  3:44   ` Ric Mason
2013-02-22 20:38   ` Hugh Dickins
2013-02-22 20:38     ` Hugh Dickins
2013-02-24  1:39     ` Ric Mason
2013-02-24  1:39       ` Ric Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5126F360.1060507@gmail.com \
    --to=ric.masonn@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=izik.eidus@ravellosystems.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=pholasek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.