Subject: Re: [PATCH, v10 3/3] cgroups: introduce timer slack controller
Date: Monday 17th October 2011 01:39:21 UTC (over 5 years ago)
On Sat, 15.10.11 21:11, Peter Zijlstra ([email protected]) 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.