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 2/7] ksm: treat unstable nid like in stable tree
Date: Wed, 06 Mar 2013 10:37:34 +0800 [thread overview]
Message-ID: <5136ABEE.8000501@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1303011833490.23290@eggly.anvils>
On 03/02/2013 10:57 AM, Hugh Dickins wrote:
> On Sat, 2 Mar 2013, Ric Mason wrote:
>> On 03/02/2013 04:03 AM, Hugh Dickins wrote:
>>> On Fri, 1 Mar 2013, Ric Mason wrote:
>>>> I think the ksm implementation for num awareness is buggy.
>>> Sorry, I just don't understand your comments below,
>>> but will try to answer or question them as best I can.
>>>
>>>> For page migratyion stuff, new page is allocated from node *which page is
>>>> migrated to*.
>>> Yes, by definition.
>>>
>>>> - when meeting a page from the wrong NUMA node in an unstable tree
>>>> get_kpfn_nid(page_to_pfn(page)) *==* page_to_nid(tree_page)
>>> I thought you were writing of the wrong NUMA node case,
>>> but now you emphasize "*==*", which means the right NUMA node.
>> Yes, I mean the wrong NUMA node. During page migration, new page has already
>> been allocated in new node and old page maybe freed. So tree_page is the
>> page in new node's unstable tree, page is also new node page, so
>> get_kpfn_nid(page_to_pfn(page)) *==* page_to_nid(tree_page).
> I don't understand; but here you seem to be describing a case where two
> pages from the same NUMA node get merged (after both have been migrated
> from another NUMA node?), and there's nothing wrong with that,
> so I won't worry about it further.
For the case of a ksm page is migrated to a different NUMA node and
migrate its stable node to the right tree and collide with an existing
stable node. get_kpfn_nid(stable_node->kpfn) != NUMA(stable_node->nid)
can capture nothing since stable_node is the node in the right stable
tree, nothing happen to it before this check. Did you intend to check
get_kpfn_nid(page_node->kpfn) != NUMA(page_node->nid) ?
>
>>>> - meeting a page which is ksm page before migration
>>>> get_kpfn_nid(stable_node->kpfn) != NUMA(stable_node->nid) can't
>>>> capture
>>>> them since stable_node is for tree page in current stable tree. They are
>>>> always equal.
>>> When we meet a ksm page in the stable tree before it's migrated to another
>>> NUMA node, yes, it will be on the right NUMA node (because we were careful
>>> only to merge pages from the right NUMA node there), and that test will not
>>> capture them. It's for capturng a ksm page in the stable tree after it has
>>> been migrated to another NUMA node.
>> ksm page migrated to another NUMA node still not freed, why? Who take page
>> count of it?
> The old page, the one which used to be a ksm page on the old NUMA node,
> should be freed very soon: since it was isolated from lru, and its page
> count checked, I cannot think of anything to hold a reference to it,
> apart from migration itself - so it just needs to reach putback_lru_page(),
> and then may rest awhile on __lru_cache_add()'s pagevec before being freed.
>
> But I don't see where I said the old page was still not freed.
>
>> If not freed, since new page is allocated in new node, it is
>> the copy of current ksm page, so current ksm doesn't change,
>> get_kpfn_nid(stable_node->kpfn) *==* NUMA(stable_node->nid).
> But ksm_migrate_page() did
> VM_BUG_ON(stable_node->kpfn != page_to_pfn(oldpage));
> stable_node->kpfn = page_to_pfn(newpage);
> without changing stable_node->nid.
>
> Hugh
--
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 2/7] ksm: treat unstable nid like in stable tree
Date: Wed, 06 Mar 2013 10:37:34 +0800 [thread overview]
Message-ID: <5136ABEE.8000501@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1303011833490.23290@eggly.anvils>
On 03/02/2013 10:57 AM, Hugh Dickins wrote:
> On Sat, 2 Mar 2013, Ric Mason wrote:
>> On 03/02/2013 04:03 AM, Hugh Dickins wrote:
>>> On Fri, 1 Mar 2013, Ric Mason wrote:
>>>> I think the ksm implementation for num awareness is buggy.
>>> Sorry, I just don't understand your comments below,
>>> but will try to answer or question them as best I can.
>>>
>>>> For page migratyion stuff, new page is allocated from node *which page is
>>>> migrated to*.
>>> Yes, by definition.
>>>
>>>> - when meeting a page from the wrong NUMA node in an unstable tree
>>>> get_kpfn_nid(page_to_pfn(page)) *==* page_to_nid(tree_page)
>>> I thought you were writing of the wrong NUMA node case,
>>> but now you emphasize "*==*", which means the right NUMA node.
>> Yes, I mean the wrong NUMA node. During page migration, new page has already
>> been allocated in new node and old page maybe freed. So tree_page is the
>> page in new node's unstable tree, page is also new node page, so
>> get_kpfn_nid(page_to_pfn(page)) *==* page_to_nid(tree_page).
> I don't understand; but here you seem to be describing a case where two
> pages from the same NUMA node get merged (after both have been migrated
> from another NUMA node?), and there's nothing wrong with that,
> so I won't worry about it further.
For the case of a ksm page is migrated to a different NUMA node and
migrate its stable node to the right tree and collide with an existing
stable node. get_kpfn_nid(stable_node->kpfn) != NUMA(stable_node->nid)
can capture nothing since stable_node is the node in the right stable
tree, nothing happen to it before this check. Did you intend to check
get_kpfn_nid(page_node->kpfn) != NUMA(page_node->nid) ?
>
>>>> - meeting a page which is ksm page before migration
>>>> get_kpfn_nid(stable_node->kpfn) != NUMA(stable_node->nid) can't
>>>> capture
>>>> them since stable_node is for tree page in current stable tree. They are
>>>> always equal.
>>> When we meet a ksm page in the stable tree before it's migrated to another
>>> NUMA node, yes, it will be on the right NUMA node (because we were careful
>>> only to merge pages from the right NUMA node there), and that test will not
>>> capture them. It's for capturng a ksm page in the stable tree after it has
>>> been migrated to another NUMA node.
>> ksm page migrated to another NUMA node still not freed, why? Who take page
>> count of it?
> The old page, the one which used to be a ksm page on the old NUMA node,
> should be freed very soon: since it was isolated from lru, and its page
> count checked, I cannot think of anything to hold a reference to it,
> apart from migration itself - so it just needs to reach putback_lru_page(),
> and then may rest awhile on __lru_cache_add()'s pagevec before being freed.
>
> But I don't see where I said the old page was still not freed.
>
>> If not freed, since new page is allocated in new node, it is
>> the copy of current ksm page, so current ksm doesn't change,
>> get_kpfn_nid(stable_node->kpfn) *==* NUMA(stable_node->nid).
> But ksm_migrate_page() did
> VM_BUG_ON(stable_node->kpfn != page_to_pfn(oldpage));
> stable_node->kpfn = page_to_pfn(newpage);
> without changing stable_node->nid.
>
> Hugh
next prev parent reply other threads:[~2013-03-06 2:37 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
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 [this message]
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=5136ABEE.8000501@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.