* [RFC] another scheduler beater
@ 2007-04-23 21:55 Bill Davidsen
2007-04-24 4:36 ` Mike Galbraith
2007-04-24 8:17 ` Ingo Molnar
0 siblings, 2 replies; 4+ messages in thread
From: Bill Davidsen @ 2007-04-23 21:55 UTC (permalink / raw)
To: Linux Kernel M/L
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
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 :-(
[-- Attachment #2: glitch1.sh --]
[-- Type: application/x-sh, Size: 377 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] another scheduler beater
2007-04-23 21:55 [RFC] another scheduler beater Bill Davidsen
@ 2007-04-24 4:36 ` Mike Galbraith
2007-04-24 8:17 ` Ingo Molnar
1 sibling, 0 replies; 4+ messages in thread
From: Mike Galbraith @ 2007-04-24 4:36 UTC (permalink / raw)
To: davidsen; +Cc: Linux Kernel M/L
On Mon, 2007-04-23 at 17:55 -0400, Bill Davidsen wrote:
> 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.
Yeah, I was testing a UP kernel yesterday. It doesn't take much renice
to severely injure the competition with them having no place else to go.
Nice -19 is definitely overkill.
-Mike
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] another scheduler beater
2007-04-23 21:55 [RFC] another scheduler beater Bill Davidsen
2007-04-24 4:36 ` Mike Galbraith
@ 2007-04-24 8:17 ` Ingo Molnar
2007-04-24 12:06 ` Ed Tomlinson
1 sibling, 1 reply; 4+ messages in thread
From: Ingo Molnar @ 2007-04-24 8:17 UTC (permalink / raw)
To: davidsen; +Cc: Linux Kernel M/L
* Bill Davidsen <davidsen@tmr.com> 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.
Ingo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] another scheduler beater
2007-04-24 8:17 ` Ingo Molnar
@ 2007-04-24 12:06 ` Ed Tomlinson
0 siblings, 0 replies; 4+ messages in thread
From: Ed Tomlinson @ 2007-04-24 12:06 UTC (permalink / raw)
To: Ingo Molnar; +Cc: davidsen, Linux Kernel M/L, Con Kolivas
On Tuesday 24 April 2007 04:17, Ingo Molnar wrote:
>
> * Bill Davidsen <davidsen@tmr.com> 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)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-04-24 12:07 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-23 21:55 [RFC] another scheduler beater Bill Davidsen
2007-04-24 4:36 ` Mike Galbraith
2007-04-24 8:17 ` Ingo Molnar
2007-04-24 12:06 ` Ed Tomlinson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).