On Wed, Nov 06, 2013 at 02:53:44PM +0100, Martin Schwidefsky wrote: > On Tue, 5 Nov 2013 23:27:52 +0100 > Peter Zijlstra <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
