From: Con Kolivas <kernel@kolivas.org>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Peter Williams <pwil3058@bigpond.net.au>,
Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Schedulers benchmark - Was: [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6
Date: Sat, 20 Aug 2005 10:31:59 +1000 [thread overview]
Message-ID: <200508201031.59981.kernel@kolivas.org> (raw)
In-Reply-To: <1124482411.25424.49.camel@mindpipe>
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
next prev parent reply other threads:[~2005-08-20 0:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-15 4:46 [ANNOUNCE][RFC] PlugSched-5.2.4 for 2.6.12 and 2.6.13-rc6 Peter Williams
2005-08-15 12:29 ` Michal Piotrowski
[not found] ` <43012427.9080406@bigpond.net.au>
[not found] ` <4301330B.3070400@bigpond.net.au>
2005-08-16 12:54 ` Michal Piotrowski
2005-08-17 8:00 ` Con Kolivas
2005-08-17 11:23 ` Michal Piotrowski
2005-08-17 12:31 ` Con Kolivas
2005-08-16 21:49 ` Schedulers benchmark - Was: " Michal Piotrowski
2005-08-17 8:10 ` Peter Williams
2005-08-17 9:03 ` Con Kolivas
2005-08-17 18:04 ` Michal Piotrowski
2005-08-17 21:35 ` Con Kolivas
2005-08-17 23:15 ` Peter Williams
2005-08-17 23:16 ` Con Kolivas
2005-08-17 23:48 ` Peter Williams
2005-08-17 23:45 ` Con Kolivas
2005-08-19 3:09 ` Michal Piotrowski
2005-08-19 3:28 ` Lee Revell
2005-08-19 3:41 ` Con Kolivas
2005-08-19 4:41 ` Peter Williams
2005-08-19 4:36 ` Con Kolivas
2005-08-19 20:13 ` Lee Revell
2005-08-20 0:31 ` Con Kolivas [this message]
2005-08-20 3:04 ` Lee Revell
2005-08-20 18:52 ` Lee Revell
2005-08-19 4:26 ` Peter Williams
2005-08-17 11:59 ` Michal Piotrowski
2005-08-21 1:34 ` Michal Piotrowski
2005-08-21 1:47 ` Con Kolivas
2005-08-21 4:16 ` Michal Piotrowski
2005-08-21 4:22 ` Con Kolivas
2005-08-21 4:44 ` Michal Piotrowski
2005-08-21 4:49 ` Con Kolivas
2005-08-21 1:37 ` Michal Piotrowski
[not found] ` <4309125B.4020707@bigpond.net.au>
2005-08-22 11:39 ` Michal Piotrowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200508201031.59981.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.k.k.piotrowski@gmail.com \
--cc=pwil3058@bigpond.net.au \
--cc=rlrevell@joe-job.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox