Re: [PATCH] 2.6.0 batch scheduling, HT aware

[Nick Piggin <piggin@cyberone.com.au>]

Pavel Machek wrote:

>Hi!
>
>
>>>BTW this is going to be an issue even on normal (non-HT)
>>>systems. Imagine memory-bound scientific task on CPU0 and nice -20
>>>memory-bound seti&home at CPU1. Even without hyperthreading, your
>>>scientific task is going to run at 50% of speed and seti&home is going
>>>to get second half. Oops.
>>>
>>>Something similar can happen with disk, but we are moving out of
>>>cpu-scheduler arena with that.
>>>
>>>[I do not have SMP nearby to demonstrate it, anybody wanting to
>>>benchmark a bit?]
>>>
>>This is definitely the case but there is one huge difference. If you have 
>>2x1Ghz non HT processors then the fastest a single threaded task can run is 
>>at 1Ghz. If you have 1x2Ghz HT processor the fastest a single threaded task 
>>can run is 2Ghz. 
>>
>
>Well, gigaherz is not the *only* important thing.
>
>On 2x1GHz, 2GB/sec RAM bandwidth, fastest a single threaded task can
>run is 1GHz, 2GB/sec. If you run two of them, it is 1GHz,
>*1*GB/sec. So you still have effect similar to hyperthreading. And
>yes, it can be measured.
>

Hi Pavel,
Sure this might be a real problem sometimes, but I don't see the
CPU scheduler ever handling it unless we want to add a few kitchen
sinks to its nice lean code as well.

If the need really arises, then probably a userspace daemon could
do it.