public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
* 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