lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ