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

Lennert Buytenhek buytenh at
Fri Mar 2 04:36:59 EST 2012

One problem you can get into with this scheme is a kind of priority
inversion.  If the low priority process does:

	fd = open("/foo/bar", O_RDWR);
	flock(fd, LOCK_EX);

and the high priority process then also does:

	fd = open("/foo/bar", O_RDWR);
	flock(fd, LOCK_EX);

and the low priority process then does:

	flock(fd, LOCK_UN);

and the system then goes into suspend, you'll not wake up again
after that second expires, and you might not wake up again soon
at all.  The low priority process doesn't even have to sleep
explicitly, if it takes a page fault you get basically the same

Nice levels don't seem the right method of controlling which tasks
get to wake up the CPU and which don't, but note that a simple
per-process "will/won't wake up the CPU" flag won't avoid the above
scenario either.

On Fri, Mar 02, 2012 at 12:38:40AM -0800, John Gilmore 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 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
> Devel at

More information about the Devel mailing list