Although the idea sounds good, the mechanism of using nice is very 2007 :-) This should be accomplished by putting this type of process in a specific cgroup. We can then use the cgroup freezer to freeze all tasks in that group, and thaw it when we see fit.
I used a similar mechanism to fix the problem where my wife would have all sorts of flash things running in different tabs of her web browser, when I was switched over to my user profile on the netbook. I added some hooks into policy kit to thaw the background users cgroup and unthaw the logged in user. Really I could have just limited the amount of processor resources they had access to, but why waste the battery? Other than that I think this could be a very good thing. I also think this would be a good way to control things that we only want to run when plugged in. No reason to run some of those cpu intensive cron jobs when running on battery. -Jon On Mar 2, 2012 9:44 AM, "John Gilmore" <[email protected]> wrote: > > Here's a power-saving idea that's been marinating since 2007 (in an > obscure corner of my mail queue). When I reviewed it today I didn't > see anything too wrong with it. > > John > > Message-Id: <[email protected]> > To: gnu > Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU > Date: Wed, 24 Oct 2007 02:12:01 -0700 > From: John Gilmore <[email protected]> > > An easy lever for CPU consumption management (power mgmt) would be to > define a set of user processes that won't be scheduled in a > power-suspended system. They won't wake the CPU even if their timer > goes off, their packet arrives, or their fairy godmother calls. But > if something else wakes the CPU, and it's going to stay running a bit > while some higher priority process is waiting for flash or packets or > something, these processes can run in the background. > > My idea is to tie this to "nice". So if you "nice -20", it puts you into > this range. Say everything below -15, which lets you set a few priorities > among the low priority background stuff. > > So if you nice things all the way down, they run when the CPU is powered, > in the cracks when there's nothing else to do, but they don't cause the CPU > to wake up to service them if nothing else is going on. > > For example, code that polls and updates the battery status once a > minute in HAL. Or a system activity monitor that shows CPU state > graphs or how many MHz we're running. Or an RSS feed reader. Or the > thing that clears out Mozilla's cache. Or the incremental backup > daemon that copies the machine's state to the school server. (If that > ran with scavenged electricity, cool! It can raise its priority once > a day or so, to make sure that a backup gets done one way or another.) > > The GUI could have a way to throw a process into this state or out of it. > E.g. push your mail reader there, polling every once in a while for email, > opportunistically. > > John > > ------- End of Forwarded Message > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
