lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 08 Mar 2013 07:26:31 +0800
From:	Ric Mason <ric.masonn@...il.com>
To:	Hugh Dickins <hughd@...gle.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Petr Holasek <pholasek@...hat.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Izik Eidus <izik.eidus@...ellosystems.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/7] ksm: treat unstable nid like in stable tree

Ping Hugh, :-)
On 03/06/2013 06:18 PM, Ric Mason wrote:
> Hi Hugh,
> On 03/06/2013 01:05 PM, Hugh Dickins wrote:
>> On Wed, 6 Mar 2013, Ric Mason wrote:
>> [ I've deleted the context because that was about the unstable tree,
>>    and here you have moved to asking about a case in the stable tree. ]
>
> I think I can basically understand you, please correct me if something 
> wrong.
>
> For ksm page:
> If one ksm page(in old node) migrate to another(new) node(ksm page is 
> treated as old page, one new page allocated in another node now), 
> since we can't get right lock in this time, we can't move stable node 
> to its new tree at this time, stable node still in old node and 
> stable_node->nid still store old node value. If ksmd scan and compare 
> another page in old node and search stable tree will figure out that 
> stable node relevant ksm page is migrated to new node, stable node 
> will be erased from old node's stable tree and link to migrate_nodes 
> list. What's the life of new page in new node? new page will be scaned 
> by ksmd, it will search stable tree in new node and if doesn't find 
> matched stable node, the new node is deleted from migrate_node list 
> and add to new node's table tree as a leaf, if find stable node in 
> stable tree, they will be merged. But in special case, the stable node 
> relevant  ksm page can also migrated, new stable node will replace the 
> stable node which relevant page migrated this time.
> For unstable tree page:
> If search in unstable tree and find the tree page which has equal 
> content is migrated, just stop search and return, nothing merged. The 
> new page in new node for this migrated unstable tree page will be 
> insert to unstable tree in new node.
>
>>> 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
>> That's not so: as I've pointed out before, ksm_migrate_page() updates
>> stable_node->kpfn for the new page on the new NUMA node; but it cannot
>> (get the right locking to) move the stable_node to its new tree at 
>> that time.
>>
>> It's moved out once ksmd notices that it's in the wrong NUMA node tree -
>> perhaps when one its rmap_items reaches the head of 
>> cmp_and_merge_page(),
>> or perhaps here in stable_tree_search() when it matches another page
>> coming in to cmp_and_merge_page().
>>
>> You may be concentrating on the case when that "another page" is a ksm
>> page migrated from a different NUMA node; and overlooking the case of
>> when the matching ksm page in this stable tree has itself been migrated.
>>
>>> 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) ?
>> Certainly not: page_node is usually NULL.  But I could have checked
>> get_kpfn_nid(stable_node->kpfn) != nid: I was duplicating the test
>> from cmp_and_merge_page(), but here we do have local variable nid.
>>
>> Hugh
>

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ