<p>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.</p>

<p>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?</p>

<p>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.</p>

<p>-Jon</p>
<p>On Mar 2, 2012 9:44 AM, "John Gilmore" <<a href="mailto:gnu@toad.com">gnu@toad.com</a>> wrote:<br>
><br>
> Here's a power-saving idea that's been marinating since 2007 (in an<br>
> obscure corner of my mail queue).  When I reviewed it today I didn't<br>
> see anything too wrong with it.<br>
><br>
>        John<br>
><br>
> Message-Id: <<a href="mailto:200710240912.l9O9C1k2026420@new.toad.com">200710240912.l9O9C1k2026420@new.toad.com</a>><br>
> To: gnu<br>
> Subject: OLPC idea: set a niceness value under which a process won't awaken suspended CPU<br>
> Date: Wed, 24 Oct 2007 02:12:01 -0700<br>
> From: John Gilmore <<a href="mailto:gnu@toad.com">gnu@toad.com</a>><br>
><br>
> An easy lever for CPU consumption management (power mgmt) would be to<br>
> define a set of user processes that won't be scheduled in a<br>
> power-suspended system.  They won't wake the CPU even if their timer<br>
> goes off, their packet arrives, or their fairy godmother calls.  But<br>
> if something else wakes the CPU, and it's going to stay running a bit<br>
> while some higher priority process is waiting for flash or packets or<br>
> something, these processes can run in the background.<br>
><br>
> My idea is to tie this to "nice".  So if you "nice -20", it puts you into<br>
> this range.  Say everything below -15, which lets you set a few priorities<br>
> among the low priority background stuff.<br>
><br>
> So if you nice things all the way down, they run when the CPU is powered,<br>
> in the cracks when there's nothing else to do, but they don't cause the CPU<br>
> to wake up to service them if nothing else is going on.<br>
><br>
> For example, code that polls and updates the battery status once a<br>
> minute in HAL.  Or a system activity monitor that shows CPU state<br>
> graphs or how many MHz we're running.  Or an RSS feed reader.  Or the<br>
> thing that clears out Mozilla's cache.  Or the incremental backup<br>
> daemon that copies the machine's state to the school server.  (If that<br>
> ran with scavenged electricity, cool!  It can raise its priority once<br>
> a day or so, to make sure that a backup gets done one way or another.)<br>
><br>
> The GUI could have a way to throw a process into this state or out of it.<br>
> E.g. push your mail reader there, polling every once in a while for email,<br>
> opportunistically.<br>
><br>
>        John<br>
><br>
> ------- End of Forwarded Message<br>
><br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/devel">http://lists.laptop.org/listinfo/devel</a><br>
</p>