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

John Gilmore gnu at toad.com
Fri Mar 2 03:38:40 EST 2012


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 new.toad.com>
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 toad.com>

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




More information about the Devel mailing list