On Mon, 2011-10-17 at 04:22 +0100, Matthew Garrett wrote: > > I agree. We can't assume perfect software, and I don't think *requiring* > the duplication of this functionality in every single session > application is sensible. We want to be able to shut down timer based > code when the session is idle. We could do this by exposing the slack in > /proc. We could do this by modifying every piece of code to listen for > session idle events and (independently) enact session-wide policy. Or we > could just accept that it's a problem that maps onto what people are > already using cgroups for and implement it in the same way. So what about the app that is both screen oriented and has a server part, say some multi-player game thing. Suppose you run one as a server but leave the client idle (you go have dinner with a pretty lady instead of playing quake, but leave your machine up to serve for your nerd friends). Should your friends get punished with a horrible gaming experience just because you're having a good time IRL and your screen went blank? Sure pushing up timer slack will save you power, but it will also hurt people, what will you do for them? The same that you do for those that want to run a CGROUP=n kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
