Hi, On Tue, May 29, 2012 at 10:53:32AM -0500, Christoph Lameter wrote: > then does the distribution of the load on its own. NUMA aware applications > like that do not benefit and do not need either of the mechanisms proposed > here. Agreed. Who changes the apps to optimize things to that lowlevel, I doubt wants to risk to hit on on a migrate on fault (or AutoNUMA async migration for that matter). > I think the proof that we need is that a general mix of applications > actually benefits from an auto migration scheme. I would also like to see Agreed. > that it does no harm to existing NUMA aware applications. As far as AutoNUMA is concerned, it will be a total bypass whenever the mpol isn't MPOL_DEFAULT. So it shouldn't harm. Shared memory is also bypassed. It only alters the beahvior of MPOL_DEFAULT, any other kind of mempolicy is unaffected, and all CPU bindings are also unaffected. If an app has only a few vmas that are MPOL_DEFAULT those few will be handled by AutoNUMA. If people thinks AutoMigration is a better name I should rename it. It's up to you. I thought using a "NUMA" suffix would make it more intuitive that if your hardware isn't NUMA, this won't do anything at all. Migration as a feature isn't limited to NUMA (see compaction etc..). Comments welcome. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>