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

[Matthew Garrett]

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?

> 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) in preference to merging a piece 
of code that's functionally consistent with the rest of the cgroups 
infrastructure?

-- 
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/