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

[Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>]

On Sat, 15.10.11 21:11, Peter Zijlstra (peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org) wrote:

> > consider you have one or more desktop user sessions logged in, each one
> > in a timer slack cgroup. Now, userspace already tracks when sessions
> > become idle (i.e. currently desktop userspace then starts a screensaver,
> > or turns off the screen, or similar), and we'd like to increase the timer slack
> > for the session cgroups individually as the individual session becomes
> > idle, and decrease it again if the session stops being idle.
> 
> > What matters for us here is that the timer slack cgroup controller
> > provides us with a very nice way to change the timerslack for the whole
> > set of session processes in one go and from the outside. i.e. the idle
> > logic in userspace would be trivially easy to implement, since we
> > already track per-session idle states and with the timerlsack cgroup
> > controller we'd have to touch only a single kernel file to make our
> > changes.
> 
> I would argue this is an excellent reason not to merge this. This really
> is in the camp of lets paper over shitty userspace instead of fix it.
> 
> Such a scheme takes away the immediate need to fix crap and therefore
> crap will not get fixed. Why not focus on creating tools (I think
> powertop really already does everything you need) and track down WTF
> apps are firing so many timers when the screen if off.

Well, maybe that works in fantasy land. In real life however there's
stuff like closed source crap, and all kinds of other things you cannot
fix. In a world where everybody wants "apps" (i.e. 3rd party code
running with limited privileges) your chance to fix every bit of code is
gone.

Despite that: even if all software was open source, and even if we had
the manpower to fix every single project: do you honestly believe it is
such a good idea to build the idle state tracking into each program so
that it can change the timer slack from the inside, if this could be
done in a much much simpler way from the outside?

So yeah, because there'll always be closed source userspace, and because
I believe hacking userspace software should be easy and accessible to
everybody, and because we also should make it difficult to fuck up
runtime behaviour of the machine (such as power usage) I believe
enforcing logic the way we can do it with timerslack cgroups is a good
thing, not a bad thing.

> Also, the downside of your approach is that you treat all applications
> the same, what if there is a genuine need for reasonable timer response
> and your 'policy' wrecks things?

Well, if some thread needs reasonable timer response, then they probably
should be enabling RT anyway and IIRC the patch excludes RT threads when
it mucks with the timer slack. But I guess Kirill can comment on this
much better than I could.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.