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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Mar 2007 00:13:12 +0100
From:	Willy Tarreau <w@....eu>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	Al Boldi <a1426z@...ab.com>, ck list <ck@....kolivas.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

On Mon, Mar 05, 2007 at 08:49:29AM +1100, Con Kolivas wrote:
(...)
> > That's just what it did, but when you "nice make -j4", things (gears) start
> > to stutter.  Is that due to the staircase?
> 
> gears isn't an interactive task. Apart from using it as a background load to 
> check for starvation because it loads up the cpu fully (which a gpu intensive 
> but otherwise simple app like this should _not_ do) graphics card drivers and 
> interrupts and so on, I wouldn't put much credence on gears as anything else. 
> However I suspect that gears will still get a fair share of the cpu on RSDL 
> which almost never happens on any other scheduler.

Con,

I've now given it a try with HZ=250 on my dual-athlon. 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.

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 !

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.

Cheers,
Willy

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