Messages in this thread | | | Date | Wed, 6 Nov 2013 15:08:07 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC][PATCH v5 01/14] sched: add a new arch_sd_local_flags for sched_domain init |
| |
On Wed, Nov 06, 2013 at 02:53:44PM +0100, Martin Schwidefsky wrote: > On Tue, 5 Nov 2013 23:27:52 +0100 > Peter Zijlstra <peterz@infradead.org> wrote: > > > On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote: > > > Your proposal looks fine for me. It's clearly better to move in one > > > place the configuration of sched_domain fields. Have you already got > > > an idea about how to let architecture override the topology? > > > > Maybe something like the below -- completely untested (my s390 compiler > > is on a machine that's currently powered off). > > In principle I do not see a reason why this should not work, but there > are a few more things to take care of. E.g. struct sd_data is defined > in kernel/sched/core.c, cpu_cpu_mask as well. These need to be moved > to a header where arch/s390/kernel/smp.c can pick it up. > > I do have the feeling that the sched_domain_topology should be left > where they are, or do we really want to expose more of the scheduler > internals?
Ah, its a trade off; in that previous patch I removed the entire sched_domain initializers the archs used to 'have' to fill out. That exposed far too much behavioural stuff the archs really shouldn't bother with.
In return we now provide a (hopefully) simpler interface that allows archs to communicate their topology to the scheduler -- without getting mixed up in the behavioural aspects (too much).
Maybe s390 wasn't the best example to pick, as the book domain really isn't that exciting. Arguably I should have taken Power7+ and the ASYM_PACKING SMT thing.
| |