Re: BUG in ht-aware scheduler/nice in 2.6.7-rc2 on dual xeon

[Con Kolivas <kernel@kolivas.org>]

On Mon, 7 Jun 2004 18:56, bert hubert wrote:
> Con, Ingo, List,
>
> I'm overjoyed with decent ht-aware scheduling in 2.6.7-rc2 and it does
> mostly the right thing. However, the 'nice' work by Con shows some slight
> problems.
>
> Please find attached program 'eat-time.cc'. Make sure not to compile it
> with -O which might confuse things as this program basically does nothing.
>
> Run it without arguments to determine the speed of 1 cpu, it outputs a
> number (megaloops/second). Then start it with that number as a parameter:
>
> Sample:
>
> $ ./eat-time
> 592
> $ ./eat-time 592
> 99%
> 99%
> 100%
> etc
>
> Now starting four of these at the same time gives the desired result:
>
> $ ./eat-time 592 & ./eat-time 592 & ./eat-time 592 & ./eat-time 592
> 50%
> 50%
> 50%
> 50%
> etc
>
> This however:
>
> $ ./eat-time 592 & ./eat-time 592 &
> 100%
> 99%
> In another xterm:
> $ nice -n +19 ./eat-time 592 & nice -n +19 ./eat-time 592
> 5%
> 5%
> 5%
>
> Fails sometimes, with all processes getting 50%. The above 'screenshot' is
> from the working and expected situation, which happens most of the time.
>
> When it goes wrong, top shows me that Cpu0 and Cpu1 are 100% user, while
> Cpu2 and Cpu3 are both 100% nice.  The niced processes show up in top as
> PRiority 39, the unniced ones (NI = 0) as PR 25.

This is just because the scheduler balancing is not aware of nice and when two 
same niceness tasks are on the same physical core they get equal shares. The 
ht-aware nice only works at keeping different nice values on the same 
physical core fair. There is no more that can be done using the current ht 
aware mechanism; a far more complicated balancing algorithm that takes nice 
into account would be required.

Con