Messages in this thread | | | Subject | Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller | From | Peter Zijlstra <> | Date | Mon, 17 Oct 2011 16:28:27 +0200 |
| |
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.
| |