On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote: > > * Rik van Riel <riel@xxxxxxxxxx> wrote: > > > On 08/22/2012 10:58 AM, Andrea Arcangeli wrote: > > >Hello everyone, > > > > > >Before the Kernel Summit, I think it's good idea to post a new > > >AutoNUMA24 and to go through a new review cycle. The last review cycle > > >has been fundamental in improving the patchset. Thanks! > > > > Thanks for improving the code and incorporating all our > > feedback. The AutoNUMA codebase is now in a state where I can > > live with it. > > > > I hope the code will be acceptable to others, too. > > Lots of scheduler changes. Has all of peterz's review feedback > been addressed? git diff --stat origin kernel/sched/ kernel/sched/Makefile | 1 + kernel/sched/core.c | 1 + kernel/sched/fair.c | 86 ++++++- kernel/sched/numa.c | 604 +++++++++++++++++++++++++++++++++++++++++++++++++ kernel/sched/sched.h | 19 ++ 5 files changed, 699 insertions(+), 12 deletions(-) Lots of scheduler changes only if CONFIG_AUTONUMA=y. If CONFIG_AUTONUMA=n it's just 107 lines of scheduler changes (numa.c won't get built in that case). > Hm, he isn't even Cc:-ed, how is that supposed to work? I separately forwarded him the announcement email because I wanted to add a few more (minor) details for him. Of course Peter's review is fundamental and appreciated and already helped to make the code a lot better. His previous comments should have been addressed, the documentation of sched_autonuma_balance has been rewritten from scratch, PF_THREAD_BOUND is gone, etc... It's possible we'll have to go through more rewrites of the docs if this still isn't good enough. I don't know yet. This is what the review is about after all :). numa.c is self contained but I see it as a plus that it's self contained. First it's easy to nuke AutoNUMA by just deleting the .[ch] files and fixing up the build errors as result in case a better algorithm emerges in the future. Second it's trivial to proof those 107 lines won't regress CFS when CONFIG_AUTONUMA=n. About the CFS integration: sched_autonuma_balance() is simply yet another idle active load balancing method. The idle active load balancing that with hyperthreading takes care of distributing the threads to be sure to fill all idle cores, in principle works identical to AutoNUMA. It also works side by side with CFS and moves tasks under CFS control (without CFS possibly noticing) to optimize for HT. numa.c in principle does the exact same thing (and it also calls the very same stop_one_cpu_nowait to do the migrations) but it optimizes for NUMA instead of HT. Thanks, Andrea -- 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>