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

[Nick Piggin <piggin _at_ xxxxxxxxxxxxxxx>]

Con Kolivas wrote:

>On Tue, 3 Feb 2004 21:58, Ingo Molnar wrote:
>
>>* Con Kolivas <kernel _at_ kolivas.org> 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 _at_ kolivas.org> 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 _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/