Re: [RFC] another scheduler beater
From: Ed Tomlinson
Date: Tue Apr 24 2007 - 08:08:01 EST
On Tuesday 24 April 2007 04:17, Ingo Molnar wrote:
> * Bill Davidsen <davidsen@xxxxxxx> wrote:
> > The small attached script does a nice job of showing animation
> > glitches in the glxgears animation. I have run one set of tests, and
> > will have several more tomorrow. I'm off to a poker game, and would
> > like to let people draw their own conclusions.
> > Based on just this script as load I would say renice on X isn't a good
> > thing. Based on one small test, I would say that renice of X in
> > conjunction with heavy disk i/o and a single fast scrolling xterm
> > (think kernel compile) seems to slow the raid6 thread measurably.
> > Results late tomorrow, it will be an early and long day :-(
> hm, i'm wondering what you would expect the scheduler to do here?
> for this particular test you'll get the best result by renicing X to
> +19! Why? Because, as far as i can see this is a partially 'inverted'
> test of X's scheduling.
> While the script is definitely useful (you taught me that nice xterm
> -geom trick to automate the placing of busy xterms :), some caveats do
> apply when interpreting the results:
> If you have a kernel 3D driver (which you seem to have, judging by the
> glxgears numbers you are getting) then running 'glxgears' wont involve X
> at all. glxgears just gets its own window and then the kernel driver
> draws straight into it, without any side-trips to X. You can see this
> for yourself by starting glitch1.sh from an ssh terminal, and then
> _totally stop_ the X server via "kill -STOP 12345" - all the xterms will
> stop, the X desktop freezes, but the glxgears instance will still
> happily draw its stuff and wheels are happily turning on the screen.
> So in this sense glxgears is a 'CPU hog' workload, largely independent
> of X.
> now, by renicing X to -10 and running the xterms you'll definitely hurt
> "CPU hogs" - even if it happens to be a glxgears process that draws 3D
> graphics in a window provided by X. But this is precisely what is
> supposed to happen in this case. You should get the best glxgears
> performance by renicing X to _+19_, and that seems to be happening
> according to your numbers - and that's what happens in my own testing
This turns out to be only part of the story. There are two scroll options for
the glitch1 script. With 'jump' scrolling I get:
cfs v5 jump -19 500 FPS
cfs v5 jump -10 500 FPS
cfs v5 jump -5 150 FPS
cfs v5 jump 0 25 FPS
cfs v5 1 line -19 230 FPS
cfs v5 1 line -10 195 FPS
cfs v5 1 line -5 720 FPS
cfs v5 1 line 0 970 FPS
cfs v5 1 line 10 430 FPS
sd 0.46 1 line -19 0.5 FPS
sd 0.46 1 line -10 0.8 FPS
sd 0.46 1 line 0 2.3 FPS
sd 0.46 1 line 10 93 FPS
sd 0.46 1 line 19 93 FPS
sd 0.46 jump is basically the same as the 1 line case.
glxgears alone gets about 1500 FPS
So in one case nice -10 gives us the worst performance. In the other case,
where you predicted nice 19 would get the best numbers nice 0 does... Nor
does the SD scheduler produce the results predicted.
(188.8.131.52 gentoo, amd64 UP HZ=300, voluntary preempt, radeon 9200 agp with in kernel drivers)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/