lkml.org 
[lkml]   [2013]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.




\
 
 \ /
  Last update: 2013-11-06 15:41    [W:0.236 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site