Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Al Boldi <a1426z@gawab.com>]

Xavier Bestel wrote:
> On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> > Hah I just wish gears would go away. If I get hardware where it runs at
> > just the right speed it looks like it doesn't move at all. On other
> > hardware the wheels go backwards and forwards where the screen refresh
> > rate is just perfectly a factor of the frames per second (or something
> > like that).
> >
> > This is not a cpu scheduler test and you're inferring that there are cpu
> > scheduling artefacts based on an application that has bottlenecks at
> > different places depending on the hardware combination.
>
> I'd add that Xorg has its own scheduler (for X11 operations, of course),
> that has its own quirks, and chances are that it is the one you're
> testing with glxgears. And as Con said, as long as glxgears does more
> FPS than your screen refresh rate, its flickering its completely
> meaningless: it doesn't even attempt to sync with vblank. Al, you'd
> better try with Quake3 or Nexuiz, or even Blender if you want to test 3D
> interactivity under load.

Actually, games aren't really usefull to evaluate scheduler performance, due 
to their bursty nature.

OTOH, gears runs full throttle, including any of its bottlenecks. In fact, 
it's the bottlenecks that add to its realism.  It exposes underlying 
scheduler hickups visually, unless buffered by the display-driver, in which 
case you just use the vesa-driver to be sure.

If gears starts to flicker on you, just slow it down with a cpu hog like:

	# while :; do :; done &

Add as many hogs as you need to make the hickups visible.

Again, these hickups are only visible when using uneven nice+ levels.

BTW, another way to show these hickups would be through some kind of a 
cpu/proc timing-tracer.  Do we have something like that?


Thanks!

--
Al