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