Re: [PATCH 00/36] AutoNUMA24

[Andrea Arcangeli <aarcange@redhat.com>]

On Wed, Aug 22, 2012 at 11:40:48PM +0200, Ingo Molnar wrote:
> 
> * Rik van Riel <riel@redhat.com> 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@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>