Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Con Kolivas <kernel@kolivas.org>]

On Monday 05 March 2007 10:13, Willy Tarreau wrote:
> I've now given it a try with HZ=250 on my dual-athlon.

Great, thanks. The HZ should make very little difference, except for slightly 
lower latencies as you increase the HZ.

> It works 
> beautifully. I also quickly checked that playing mp3 doesn't skip during
> make -j4, and that gears runs fairly smoothly, since those are the
> references people often use.

Good. I obviously need to ensure that these remain well managed since I, for 
one, never want linux to suck on the desktop. In your case, I was more 
interested in your real world problems you were having so the rest of your 
report is even more important to me.

> But with real work, it's excellent too. When I saturate my CPUs by
> injecting HTTP traffic on haproxy, the load is stable and the command line
> perfectly responsive, while in the past the load would oscillate and the
> command line sometimes stopped to respond for a few seconds.
>
> I've also launched my scheddos program (you may remember, the one we did a
> few experiments with). I could not cause any freeze at all. Plain 2.6.20
> had already improved a lot in this area, but above 4 processes/CPU,
> occasional short freezes did still occur. This time, even at 100 processes,
> the system was rather slow (of course!) but just as expected, and nothing
> more.
>
> I also tried the good old "dd if=/dev/zero bs=1|...|dd bs=1 of=/dev/null"
> and it did not cause any trouble.
>
> I will boot 2.6 slightly more often to test the code under various
> conditions, and I will recommend it to a few people I know who tend to
> switch back to 2.4 after one day full of 2.6 jerkiness.
>
> Overall, you have done a great job !

Thank you very much. I think you have nicely pointed out some of the real 
world advantages to this design. Those testcases are good for testing average 
latency, fairness, and consistency of both of them under various loads so 
they are excellent real world examples. If you extrapolate those facts to 
server loads you can understand how the fairness and latency can translate 
into advantages anywhere.

> I hope that more people will give it a try, first to help find possible
> remaining bugs, and to pronounce in favour of its inclusion in mainline.

Thanks. I've already had a hundred or so people testing this code (thanks to 
the -ck mailing list people!) without any recent bugs prior to announcing it 
to lkml so I believe it is quite safe for testing.

-- 
-ck