From: Lee Revell <rlrevell@joe-job.com>
To: Con Kolivas <kernel@kolivas.org>
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: Fri, 19 Aug 2005 16:13:30 -0400 [thread overview]
Message-ID: <1124482411.25424.49.camel@mindpipe> (raw)
In-Reply-To: <200508191436.42881.kernel@kolivas.org>
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
next prev parent reply other threads:[~2005-08-19 20:13 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 [this message]
2005-08-20 0:31 ` Con Kolivas
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=1124482411.25424.49.camel@mindpipe \
--to=rlrevell@joe-job.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.k.k.piotrowski@gmail.com \
--cc=pwil3058@bigpond.net.au \
/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