Re: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4for 2.6.12 and 2.6.13-rc6

[Lee Revell]

On Fri, 2005-08-19 at 14:36 +1000, Con Kolivas wrote:
> On Fri, 19 Aug 2005 02:41 pm, Peter Williams wrote:
> > Maybe we could use interbench to find a nice value for X that doesn't
> > destroy Audio and Video?  The results that I just posted for
> > spa_no_frills with X reniced to -10 suggest that the other schedulers
> > could cope with something closer to zero.
> 
> I don't see the point. X works fine as is without renicing not withstanding 
> these extreme loads in interbench. Furthermore, reworking of xorg code to not 
> spin the cpu unnecessarily when the gpu is busy is underway and tuning the 
> cpu scheduler unfairly for an X server that will no longer behave so badly is 
> inappropriate.

See, that's where we disagree, I certainly don't believe X "works fine".
Compared to MacOS and (especially) Windows the Linux desktop is WAY
sluggish.

For example when I cycle through windows with alt-tab in X, it can take
5-10 seconds for each to render.  I can see the application's widgets
being drawn one at a time, then finally the border.  Repeated
alt-tabbing between the same two windows seems to cause a CPU intensive
redraw of the entire window.  It's as if X just discards the rendered
contents of a window as soon as it's obscured.

On Windows this works as expected - cycling through windows whose
contents have already been rendered is *instantaneous*.

I agree that tweaking the scheduler is probably pointless, as long as X
is burning gazillions of CPU cycles redrawing things that don't need to
be redrawn.

Then again even the OSX scheduler has hooks for the GUI.  Presumably
they concluded that the desktop responsiveness problem could not be
adequately solved within the framework of a general purpose UNIX
scheduler.

Lee

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