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]
Date:	Wed, 21 Nov 2012 14:46:14 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Mel Gorman <mgorman@...e.de>
CC:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Alex Shi <lkml.alex@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 36/46] mm: numa: Use a two-stage filter to restrict pages
 being migrated for unlikely task<->node relationships

On 11/21/2012 02:15 PM, Mel Gorman wrote:
> On Wed, Nov 21, 2012 at 07:25:37PM +0100, Ingo Molnar wrote:

>> As mentioned in my other mail, this patch of yours looks very
>> similar to the numa/core commit attached below, mostly written
>> by Peter:
>>
>>    30f93abc6cb3 sched, numa, mm: Add the scanning page fault machinery

> Just to compare, this is the wording in "autonuma: memory follows CPU
> algorithm and task/mm_autonuma stats collection"
>
> +/*
> + * In this function we build a temporal CPU_node<->page relation by
> + * using a two-stage autonuma_last_nid filter to remove short/unlikely
> + * relations.

Looks like the comment came from sched/numa, but the original code
came from autonuma:

https://lkml.org/lkml/2012/8/22/629

If you want to do a real historical dig, we may still have a picture
of the whiteboard where Karen and I came up with the idea of only
migrating a page after the second touch from the same node :)

That was trying to solve the "how can we make migrate on fault as
cheap as possible?" question, and reviewing some earlier autonuma
codebase.

Not that any of this matters in the least.  AutoNUMA, sched/numa,
and balancenuma have all evolved a lot because they were able to
copy good ideas from each other, and discard overly complex or
simply bad ideas (eg. the NUMA syscalls or async page migration),
while replacing them with simpler, better ideas from the other
code bases.

Now that we (mostly) agree on what the basic infrastructure should
look like, we can figure out which placement policies work best for
various workloads.

Then we can make a choice depending on what works best, independent
of who wrote what.

-- 
All rights reversed
--
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