lkml.org 
[lkml]   [2005]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
    Date
    On Sat, 20 Aug 2005 06:13, Lee Revell wrote:
    > 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.

    It's an X problem and it's being fixed. Get over it, we're not tuning the
    scheduler for a broken app.

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

    \
     
     \ /
      Last update: 2005-08-20 02:34    [W:0.070 / U:59.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site