[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1173717518.26350.6.camel@localhost>
Date: Mon, 12 Mar 2007 17:38:38 +0100
From: Kasper Sandberg <lkml@...anurb.dk>
To: Con Kolivas <kernel@...ivas.org>
Cc: Xavier Bestel <xavier.bestel@...e.fr>,
Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
linux kernel mailing list <linux-kernel@...r.kernel.org>,
ck list <ck@....kolivas.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
On Mon, 2007-03-12 at 21:34 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> > On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > > Hmm. So... anything that's client/server is going to suffer horribly
> > > > unless niced tasks are niced all the way down to 19?
> > >
> > > Fortunately most client server models dont usually have mutually
> > > exclusive cpu use like this X case. There are many things about X that
> > > are still a little (/me tries to think of a relatively neutral term)...
> > > wanting. :(
> >
> > I'd say the problem is less with X than with Xlib, which is heavily
> > round-trip-based. Fortunately XCB (its successor) seeks to be more
> > asynchronous.
>
> Yes I recall a talk by Keith Packard on Xorg development and how a heck of a
> lot of time spent spinning by X (?Xlib) for no damn good reason was the
> number one thing that made X suck and basically it was silly to try and fix
> that at the cpu scheduler level since it needed to be corrected in X, and was
> being actively addressed. So we should stop trying to write cpu schedulers
> for X.
Excuse me for barging in. But.
with latest xorg, xlib will be using xcb internally, which afaik should
help matters a little, but furthermore, with the arrival of xcb, stuff
are bound to change somewhat fast, and with abit more incentive(as in,
real benefit on latest kernels), they are bound to change even faster.
and if people upgrading to newest X(using xlib w/xcb) and applications
being updated can help stuff out in the kernel, i'd say its best to push
for that.
>
> > Xav
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists