Re: [PATCH] 2.6.1 Hyperthread smart "nice" 2

[Nick Piggin]

Con Kolivas wrote:

> On Tue, 3 Feb 2004 21:58, Ingo Molnar wrote:
>
> > * Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> >
> > > At least it appears Intel are well aware of the priority problem, but
> > > full priority support across logical cores is not likely. However I
> > > guess these new instructions are probably enough to work with if
> > > someone can do the coding.
> > these instructions can be used in the idle=poll code instead of rep-nop.
> > This way idle-wakeup can be done via the memory bus in essence, and the
> > idle threads wont waste CPU time. (right now idle=poll wastes lots of
> > cycles on HT boxes and is thus unusable.)
>
> Thanks for explaining.
>
>
> > for lowprio tasks they are of little use, unless you modify gcc to
> > sprinkle mwait yields all around the 'lowprio code' - not very practical
> > i think.
>
> Yuck!
>
> Looks like the kernel is the only thing likely to be smart enough to do this 
> correctly for some time yet. 
>
> Nick, any chance of seeing something like this in your sched domains? (that 
> would be the right way unlike my hacking sched.c directly for a specific 
> architecture).

Yeah it wouldn't be too difficult

Con Kolivas wrote:

> On Tue, 3 Feb 2004 21:58, Ingo Molnar wrote:
>
> > * Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> >
> > > At least it appears Intel are well aware of the priority problem, but
> > > full priority support across logical cores is not likely. However I
> > > guess these new instructions are probably enough to work with if
> > > someone can do the coding.
> > these instructions can be used in the idle=poll code instead of rep-nop.
> > This way idle-wakeup can be done via the memory bus in essence, and the
> > idle threads wont waste CPU time. (right now idle=poll wastes lots of
> > cycles on HT boxes and is thus unusable.)
>
> Thanks for explaining.
>
>
> > for lowprio tasks they are of little use, unless you modify gcc to
> > sprinkle mwait yields all around the 'lowprio code' - not very practical
> > i think.
>
> Yuck!
>
> Looks like the kernel is the only thing likely to be smart enough to do this 
> correctly for some time yet. 
>
> Nick, any chance of seeing something like this in your sched domains? (that 
> would be the right way unlike my hacking sched.c directly for a specific 
> architecture).

Yeah it wouldn't be too difficult Con. Basically you can add a flag to
a domain to enable some scheduling "quirk".

In this case you would add a flag to the domain which balances logical
cores in the physical CPU. You can then look up your lowest domain
with cpu_sched_domain(cpu). If the domain has the required flag set,
you can look at its ->span - which in this case would give you all
logical CPUs (siblings) on this package.

I need to actually do a bit more work and verification on the SMT
setup and make sure it plays nicely with non-ht systems, but after
that I'll probably look at this issue if someone hasn't beaten me to
it.

At the moment I've got my hands pretty full though so it might take
a while...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/