idea: set a niceness value under which a process won't awaken suspended CPU

Jon Nettleton jon.nettleton at
Fri Mar 2 04:12:26 EST 2012

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


On Mar 2, 2012 9:44 AM, "John Gilmore" <gnu at> 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: <200710240912.l9O9C1k2026420 at>
> 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 <gnu at>
> 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
> 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
> Devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list