Messages in this thread | | | Subject | Re: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6 | From | Lee Revell <> | Date | Fri, 19 Aug 2005 16:13:30 -0400 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |