linux-kernel - Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller

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: <1318862969.4172.45.camel@twins>
Date:	Mon, 17 Oct 2011 16:49:29 +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:40 +0100, Matthew Garrett wrote:
> On Mon, Oct 17, 2011 at 04:28:27PM +0200, Peter Zijlstra wrote:
> > On Mon, 2011-10-17 at 15:11 +0100, Matthew Garrett wrote:
> > > Whether or not you want the animation to carry on animating is policy, 
> > > and you need something to be the policy agent. Let's say firefox is 
> > > invisible. I now grab a copy of its window contents. What do I get?
> > 
> > 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.

The normal case is where things are visible and things are kept
up-to-date, that doesn't change.

> > >  in preference to merging a piece 
> > > of code that's functionally consistent with the rest of the cgroups 
> > > infrastructure?
> > 
> > Yep.. because as of yet there isn't a sane use-case to warrant adding
> > the maintenance burden. Any cgroup controller is functionally
> > consistent, per definition, that doesn't make it useful or even sane.
> 
> 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?
--
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/