* Ingo Molnar [off-list ref] wrote:

quoted

This is prototype only but what I was using as a reference 
to see could I spot a problem in yours. It has not been even 
boot tested but avoids remote->remote copies, contending on 
PTL or holding it longer than necessary (should anyway)

So ... because time is running out and it would be nice to 
progress with this for v3.8, I'd suggest the following 
approach:

 - Please send your current tree to Linus as-is. You already 
   have my Acked-by/Reviewed-by for its scheduler bits, and my
   testing found your tree to have no regression to mainline,
   plus it's a nice win in a number of NUMA-intense workloads.
   So it's a good, monotonic step forward in terms of NUMA
   balancing, very close to what the bits I'm working on need as
   infrastructure.

 - I'll rebase all my devel bits on top of it. Instead of
   removing the migration bandwidth I'll simply increase it for
   testing - this should trigger similarly aggressive behavior.
   I'll try to touch as little of the mm/ code as possible, to
   keep things debuggable.

One minor last-minute request/nit before you send it to Linus, 
would you mind doing a:

   CONFIG_BALANCE_NUMA => CONFIG_NUMA_BALANCING

rename please? (I can do it for you if you don't have the time.)

CONFIG_NUMA_BALANCING is really what fits into our existing NUMA 
namespace, CONFIG_NUMA, CONFIG_NUMA_EMU - and, more importantly, 
the ordering of words follows the common generic -> less generic 
ordering we do in the kernel for config names and methods.

So it would fit nicely into existing Kconfig naming schemes:

   CONFIG_TRACING
   CONFIG_FILE_LOCKING
   CONFIG_EVENT_TRACING

etc.

Thanks,

	Ingo

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