linux-kernel - Re: [ck] 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] [day] [month] [year] [list]

Date:	Mon, 5 Mar 2007 23:29:44 +1100
From:	Con Kolivas <kernel@...ivas.org>
To:	Al Boldi <a1426z@...ab.com>
Cc:	Markus Törnqvist <mjt@...v.org>,
	ck list <ck@....kolivas.org>, linux-kernel@...r.kernel.org
Subject: Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

On Monday 05 March 2007 22:59, Al Boldi wrote:
> Markus Törnqvist wrote:
> > On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
> > >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
> > > gears becomes bursty.  This looks like a problem with nice-levels.  In
> > > general, looking subjectively at top d.1, procs appear to show
> > > jerkiness when nice'd.

I wouldn't place much value on what you can see just from looking at top. 
Gears just isn't an interactive task and just about anything but gears would 
be a better test case since its behaviour varies wildly under different 
combinations of graphics cards, memory bandwidth, cpu and so on. I'm not even 
sure what you're trying to prove with gears. If it's to see "smooth 
behaviour" under load then gears is not the thing to do it with. Maybe 
unbuffered live video on xawtv or something? Perhaps even capturing video 
where you know what the cpu usage will be of the video codec you're using. 
Say you knew xvid at a fixed bitrate required 30% cpu to encode a live video 
then you could see if it did it real time with a make -j2 running assuming 
you don't run out of disk bandwidth and so on. Or something that required 75% 
cpu and you ran a nice -19 make -j4. Or even try interbench and fiddle with 
the nice values and size of the loads since those options exist and see what 
the latencies and %desired cpu are. By default without arguments interbench 
looks for unfair scheduling and finds plenty of it in other scheduler 
designs. Either way your testcase must mean something to you.

> > Don't use glxgears, please. Ever. Unless you want meaningless gears.

That I definitely agree with.

> > It displays totally erratic behaviour anyway, and does sched_yield
> > (strace tells us this) which means IT GIVES UP ITS TIME TO RUN, ie yields
> > the cpu to someone else.
>
> I just strace'd it here.  It doesn't show any yield in the mesa-5.0
> version. Which version are you using?

Curious. On a machine with onboard intel graphics (915 driver), and on an ATI 
r200 dri based driver I can see yields. Yet with the nvidia driver I see no 
yields. This sched_yield seems to be more done by the driver rather than the 
application. That would cause woeful performance. How odd that modern drivers 
out there today are still using this basically defunct unix function. No, I'm 
not interested in getting into a discussion of the "possible" uses of 
sched_yield. That's been done to death many times before.

-- 
-ck
-
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/