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

[Peter Zijlstra <peterz@infradead.org>]

On Mon, 2011-10-17 at 15:11 +0100, Matthew Garrett wrote:
> On Mon, Oct 17, 2011 at 03:06:26PM +0200, Peter Zijlstra wrote:
> > On Mon, 2011-10-17 at 13:46 +0100, Matthew Garrett wrote:
> > > They're orthogonal. Sometimes you want timer-driven behaviour (how else 
> > > are you going to draw animations?) and that's obviously going to 
> > > generate wakeups. This is for the idle case, where the user is no longer 
> > > sitting in front of the machine but you don't want to trigger a full 
> > > system suspend. We either need every application that ever uses 
> > > timer-driven behaviour to support setting its own timer slack on some 
> > > sort of external policy decision, or we need a way to let the kernel 
> > > force them to.
> > 
> > No!! you want that application to stop drawing stuff that is invisible.
> > Setting your own timerslack for something you know is pointless is worse
> > than doing something pointless, its down right stupid.
> 
> 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?

> > Please, work with the X folks and make it an error to draw to invisible
> > surfaces. And yes, I know that composition makes that a non-trivial
> > problem. But at least the blank screen case should be trivial, and I
> > suspect there's more tractable cases as well. Mostly the desktop is
> > still a very static place and a few extra timer ticks for when you're
> > spinning your desktop cube around isn't going to be a problem.
> 
> So, just to be clear on this, you want to change the semantics of X and 
> modify every piece of userspace that currently uses X (because it'll now 
> otherwise crash when the screen blanks)

Or even when I minimize firefox. That said, ff will probably crash as
soon as I open a second tab because the retarded thing will very likely
continue animating everything on the invisible tab anyway.

You could start by making the X lib of the day, is that XCB these days?,
issue an error print (you get plenty of those anyway) and progress to
full on crashing later.

This gives developers a migration window and incentive to fix up their
apps.

>  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.