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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F74BFB6.5090204@redhat.com>
Date:	Thu, 29 Mar 2012 16:01:58 -0400
From:	Larry Woodman <lwoodman@...hat.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...il.com>
CC:	Christoph Lameter <cl@...ux.com>, linux-mm@...ck.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Motohiro Kosaki <mkosaki@...hat.com>
Subject: Re: [PATCH -mm] do_migrate_pages() calls migrate_to_node() even if
 task is already on a correct node

On 03/29/2012 03:43 PM, KOSAKI Motohiro wrote:
> (3/29/12 2:00 PM), Larry Woodman wrote:
>> On 03/22/2012 03:30 PM, Christoph Lameter wrote:
>>> On Thu, 22 Mar 2012, Larry Woodman wrote:
>>>
>>>>> Application may manage their locality given a range of nodes and 
>>>>> each of
>>>>> the x .. x+n nodes has their particular purpose.
>>>> So to be clear on this, in that case the intention would be move 3 
>>>> to 4, 4 to
>>>> 5 and 5 to 6
>>>> to keep the node ordering the same?
>>> Yup. Have a look at do_migrate_pages and the descrition in the 
>>> comment by
>>> there by Paul Jackson.
>>>
>>>
>> Christoph and others what do you think about this???
>>
>>
>>         for_each_node_mask(s, tmp) {
>> +
>> +            /* IFF there is an equal number of source and
>> +             * destination nodes, maintain relative node distance
>> +             * even when source and destination nodes overlap.
>> +             * However, when the node weight is unequal, never move
>> +             * memory out of any destination nodes */
>> +            if ((nodes_weight(*from_nodes) != 
>> nodes_weight(*to_nodes)) &&
>> +                        (node_isset(s, *to_nodes)))
>> +                continue;
>> +
>>             d = node_remap(s, *from_nodes, *to_nodes);
>>             if (s == d)
>>                 continue;
>
> I'm confused. Could you please explain why you choose nodes_weight()? 
> On my first impression,
> it seems almostly unrelated factor.

nodes_weight() tells us the number of nodes in the cpuset so if you are 
migrating
from say 2, 3 &4 to 3, 4 &5 we wont go from 2 to 5 and call it done like 
the original
patch did.  With this patch we will preserve the migrating of 2, 3 &4 to 
3, 4 &5  yet
if we are migrating from 0-7 to 3-4 we wont do this:

Migrating 7 to 4
Migrating 6 to 3
Migrating 5 to 4
Migrating 4 to 3
Migrating 1 to 4
Migrating 3 to 4
Migrating 0 to 3
Migrating 2 to 3

Instead, will do this:

Migrating 7 to 4
Migrating 6 to 3
Migrating 5 to 4
Migrating 1 to 4
Migrating 0 to 3
Migrating 2 to 3

Larry

>
>
> -- 
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign 
> http://stopthemeter.ca/
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

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