LWN: Comments on "Making power policy just work"

Making power policy just work

greened — Thu, 17 Jul 2008 20:19:14 +0000

It strikes me that this problem has been studied already.  For many 
applications, the kernel *can* discover usage patterns and adapt to save 
power.  See for example the Vertigo project:

http://www.arm.com/pdfs/IEMSoftwarePaper-OSDI2002.pdf

Making power policy just work

zdzichu — Mon, 07 Jul 2008 09:27:37 +0000

If I understand correctly, this is about spreading load on CPU, not cores. So dual core Intel
CPUs won't gain anything from this. But quadcore Intel laptop CPUs would, as they are still
not native QC but two dual-core sticked together.

On the other hand, AMD K10 family CPUs have very power-independent cores, so even dual-core
would benefit. AMD "Griffin" have split power-plane so I suppose this scheduling policy can
help lowering power consumption on it.

Making power policy just work

IkeTo — Sat, 05 Jul 2008 01:31:37 +0000

> | Tunables are basically "we give up, let's push the problem to the user"

> Tunables are also something for external daemons to change

So "user" means "user mode".

Making power policy just work

ikm — Thu, 03 Jul 2008 18:23:02 +0000

Would the current dual-core notebooks benefit from this, or is this server-only?

Making power policy just work

mattdm — Thu, 03 Jul 2008 15:28:23 +0000

I had a boss a while ago who liked to lecture on the difference between "urgent" and
"important". Not everything which is important needs attention right away, and there are some
things which need to be responded to quickly but which aren't, in the big picture, as
important. In this case, your bash prompt is urgent, but isn't necessarily as important as a
background application.

Making power policy just work

davecb — Thu, 03 Jul 2008 13:23:09 +0000

Andi Kleen notes that:
| Tunables are basically "we give up, let's push the problem to the user"
| which is not nice. I suspect a lot of users won't even know if their
| workloads are bursty or not. Or they might have workloads which are 
| both bursty and not bursty. 

Tunables are also something for external daemons to change: the famous
example is the IBM z/OS Workload Manager (WLM), which looks at 
application (actually workload) progress and a table of requirements 
and adjusts CPU, IO and memory tunables to speed to slow the workload.

--dave

Making power policy just work

epa — Thu, 03 Jul 2008 12:54:13 +0000

I think that 'priority' and 'interactivity' are two separate things and it's a mistake to use
a single niceness level for both.

My bash process shouldn't have a high priority if it starts chewing CPU time for long periods,
but it needs to respond quickly to user input and then go back to sleep.

Making power policy just work

dipankar — Thu, 03 Jul 2008 12:14:22 +0000

Power nice levels would be nice to have, but I would dread using them to set a global
system-wide power policy which is how it will be used in most data centers at the moment. I
don't think it would be a good idea to add another user of tasklist_lock and iterate through
every task in the system to set the power nice value.

Making power policy just work

rvfh — Thu, 03 Jul 2008 08:24:25 +0000

> Peter Zijlstra observed that he has niced processes (created with distcc) which should have
access to all of the CPU power available, but which should not contend with interactive
processes on the same system.

Maybe the interactive task should be niced upwards, rather than distcc downwards. Looks like
what he is really trying to achieve: a reactive desktop even with distcc running at full
blast.