On Tuesday 24 April 2007 04:17, Ingo Molnar wrote: > > * Bill Davidsen <[EMAIL PROTECTED]> 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 > too. I Ingo,
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. Thanks, Ed Tomlinson (2.6.20.7 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
