Thread (35 messages) flat view 35 messages, 8 authors, 2011-10-17

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

From: Matthew Garrett <hidden>
Date: 2011-10-17 14:40:59
Also in: lkml

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:
quoted
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?
quoted
 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.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help