* domain setup in 2.6.9rc1-bk6
@ 2004-08-31 9:56 Andi Kleen
2004-08-31 10:09 ` Anton Blanchard
0 siblings, 1 reply; 5+ messages in thread
From: Andi Kleen @ 2004-08-31 9:56 UTC (permalink / raw)
To: nickpiggin, akpm, linux-arch
Someone deleted arch/x86_64/kernel/domain.c in current BK
and moved the SMT domain setup to generic code.
Problem is that I need a architecture specific hook to
turn off SMT idle for AMD dual core CPUs, which otherwise
look like SMT siblings. I suppose I will do more tunings
in this area in the future anyways, so having it in the
architecture would be better.
It seems a bit counterintuitive that we have such a configurable
scheduler, and then there is only a "one size fits all" way
to configure it.
Can part of this code please be moved back to the architecture?
Thanks,
-Andi
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: domain setup in 2.6.9rc1-bk6
2004-08-31 9:56 domain setup in 2.6.9rc1-bk6 Andi Kleen
@ 2004-08-31 10:09 ` Anton Blanchard
2004-08-31 11:33 ` Andi Kleen
0 siblings, 1 reply; 5+ messages in thread
From: Anton Blanchard @ 2004-08-31 10:09 UTC (permalink / raw)
To: Andi Kleen; +Cc: nickpiggin, akpm, linux-arch
> Problem is that I need a architecture specific hook to
> turn off SMT idle for AMD dual core CPUs, which otherwise
> look like SMT siblings. I suppose I will do more tunings
> in this area in the future anyways, so having it in the
> architecture would be better.
From a ppc64 perspective I liked the merging of the domains code.
We could have the ability to override generic domain setup per
architecture but leave all the default stuff in there.
Anton
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: domain setup in 2.6.9rc1-bk6
2004-08-31 10:09 ` Anton Blanchard
@ 2004-08-31 11:33 ` Andi Kleen
2004-09-01 0:16 ` Nick Piggin
0 siblings, 1 reply; 5+ messages in thread
From: Andi Kleen @ 2004-08-31 11:33 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Andi Kleen, nickpiggin, akpm, linux-arch
On Tue, Aug 31, 2004 at 08:09:24PM +1000, Anton Blanchard wrote:
>
> > Problem is that I need a architecture specific hook to
> > turn off SMT idle for AMD dual core CPUs, which otherwise
> > look like SMT siblings. I suppose I will do more tunings
> > in this area in the future anyways, so having it in the
> > architecture would be better.
>
> From a ppc64 perspective I liked the merging of the domains code.
>
> We could have the ability to override generic domain setup per
> architecture but leave all the default stuff in there.
Currently all I want is to disable SD_SHARE_POWER when one flag
is set. A simple way to do this would be appreciated.
Later overriding would be fine. A simple way to do this would
be to declare it weak.
-Andi
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: domain setup in 2.6.9rc1-bk6
2004-08-31 11:33 ` Andi Kleen
@ 2004-09-01 0:16 ` Nick Piggin
2004-09-01 1:15 ` Andi Kleen
0 siblings, 1 reply; 5+ messages in thread
From: Nick Piggin @ 2004-09-01 0:16 UTC (permalink / raw)
To: Andi Kleen; +Cc: Anton Blanchard, Andi Kleen, akpm, linux-arch, Ingo Molnar
Andi Kleen wrote:
> On Tue, Aug 31, 2004 at 08:09:24PM +1000, Anton Blanchard wrote:
>
>>>Problem is that I need a architecture specific hook to
>>>turn off SMT idle for AMD dual core CPUs, which otherwise
>>>look like SMT siblings. I suppose I will do more tunings
>>>in this area in the future anyways, so having it in the
>>>architecture would be better.
>>
>>From a ppc64 perspective I liked the merging of the domains code.
>>
>>We could have the ability to override generic domain setup per
>>architecture but leave all the default stuff in there.
>
>
> Currently all I want is to disable SD_SHARE_POWER when one flag
> is set. A simple way to do this would be appreciated.
>
You can define ARCH_HAS_SCHED_TUNE, and define your own
SD_SIBLING_INIT, SD_CPU_INIT, SD_NODE_INIT. Also, you just
need to define a cpu_sibling_map in order to use CONFIG_SCHED_SMT.
> Later overriding would be fine. A simple way to do this would
> be to declare it weak.
>
Ingo preferred to do it this way. I can't say I blame him because
the setup code is not exactly something trivial that you want
duplicated everywhere (although it is now much improved).
It would be simple enough to just re-export it to the arch code,
however I guess I agree with tackling that when the need arises.
I think it may not be *too* difficult to even come up with a
decent API to handle more arbitrary setups now. Definitely let
me know when you run into a limitation, and I'll be interested in
fixing it.
Thanks
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: domain setup in 2.6.9rc1-bk6
2004-09-01 0:16 ` Nick Piggin
@ 2004-09-01 1:15 ` Andi Kleen
0 siblings, 0 replies; 5+ messages in thread
From: Andi Kleen @ 2004-09-01 1:15 UTC (permalink / raw)
To: Nick Piggin; +Cc: anton, ak, akpm, linux-arch, mingo
On Wed, 01 Sep 2004 10:16:16 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > Currently all I want is to disable SD_SHARE_POWER when one flag
> > is set. A simple way to do this would be appreciated.
> >
>
> You can define ARCH_HAS_SCHED_TUNE, and define your own
> SD_SIBLING_INIT, SD_CPU_INIT, SD_NODE_INIT. Also, you just
Hmm, it seems to be evaluated at run time. That may actually
work.
Basically i just need a function call to determine the flags
for SD_SIBLING_INIT.
-Andi
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-09-01 1:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-31 9:56 domain setup in 2.6.9rc1-bk6 Andi Kleen
2004-08-31 10:09 ` Anton Blanchard
2004-08-31 11:33 ` Andi Kleen
2004-09-01 0:16 ` Nick Piggin
2004-09-01 1:15 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox