Message-ID: <1318864260.4172.54.camel@twins>
Date:	Mon, 17 Oct 2011 17:11:00 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Lennart Poettering <mzxreary@...inter.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>,
	containers@...ts.linux-foundation.org,
	jacob.jun.pan@...ux.intel.com, linux-kernel@...r.kernel.org,
	Matt Helsley <matthltc@...ibm.com>, linux-api@...r.kernel.org,
	Kay Sievers <kay.sievers@...y.org>, harald@...hat.com,
	david@...ar.dk, greg@...ah.com
Subject: Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller

On Mon, 2011-10-17 at 15:59 +0100, Matthew Garrett wrote:
> On Mon, Oct 17, 2011 at 04:49:29PM +0200, Peter Zijlstra wrote:
> > On Mon, 2011-10-17 at 15:40 +0100, Matthew Garrett wrote:
> > > On Mon, Oct 17, 2011 at 04:28:27PM +0200, Peter Zijlstra wrote:
> > > > An XDamage and repaint from the X client, after which your copy will
> > > > complete and you get what you asked for?
> > > 
> > > An XDamage and then an asynchronous RPC call to the remote server to 
> > > identify the contents of the next frame before drawing them, plus some 
> > > sort of new synchronisation mechanism for blocking the X query until 
> > > that point?
> > 
> > Why would this be a problem? 
> > 
> > I mean, why would getting a copy of an otherwise invisible surface be a
> > performance sensitive path? If the compositor needs the surface it would
> > make it visible and send the XDamage once and keep it visible henceforth
> > until the time it again becomes invisible, at which point you have to
> > stop updates again.
> 
> I'm not saying that it's a problem. I'm saying that your approach 
> changes behavioural semantics in a way that may violate application 
> expectations just as surely as changing the timer behaviour does. 
> There's no free approach.

I'm not saying its free, I'm saying its a much better approach since it
gets rid of the entire problem instead of papering over the worst of it.

> > > Timers are a resource. People want to manage that resource. cgroups are 
> > > a convenient mechanism for managing resources.
> > 
> > Yes, and a ball is round (unless you're a USA-ian, in which case they're
> > ovoid), what's your point?
> 
> If there's no reason to want to manage that resource, why do we support 
> timer slack at all?

So that individual applications can provide their timing tolerance and
the OS can group these timers in order to optimize idle time or whatnot.

Indiscriminately changing the slack for a whole group of otherwise
unrelated applications will violate their timing tolerances and break
them in non-obvious ways.


  
What I'm saying is that its much better to attack the primary source of
evil in a manner that is unforgiving instead of trying to avoid the
worst excesses and cause non-obvious breakage.

For a while people were promoting the idea that its good to be lenient
in what you accept as input and strict in what you send out. I think
people are starting to realize that was a horrid mistake since now
they're getting utter crap and people don't even know what right is
anymore.
--
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