Hi!

quoted

quoted

That's a 1750mAs difference. There are of course other parts drawing
current but simple things like the above really make a difference in the
mobile space, both in terms of battery and thermal budget.

Aha, I noticed the values are now the other way around. [And notice
that if user _does_ lock/turn off the screen after the operation,
difference between power consumptions is factor of two. People do turn
off screens before putting phone back in pocket.]

It depends on the use-case, that's why the problem is so complicated.
Race-to-idle may work well if just checking bus timetables but not if
you are watching video or listening to music (the latter with screen
off).

Exactly, it is complex. That's why it is important to get real
numbers, please.

And yes, if your _system_ has low power consumption in
active-at-low-frequency mode, race-to-idle may not be a win for you.

quoted

You are right that as long as user does _not_ wait for the computation
result, running at low frequency might make sense. That may be true on
cellphone so fast that all the actions are "instant". I have yet to
see such cellphone. That probably means that staying on low frequency
normally and going to high after cpu is busy for 100msec or so is
right thing: if cpu is busy for 100msec, it probably means user is
waiting for the result.

I'm talking about use-cases where a task (or multiple threads) are
running and only loading the CPU partially (audio or video playback).
Here you have an average number of instructions to execute per decoded
frame in a certain time. Once the frame is decoded, the CPU can go idle,
so you can choose whether to race to idle or run at lower frequency (and
lower energy per the same number of frame decoding instructions) with
less idle time. There are modern platforms where the latter behaviour is
more efficient.

So, my Thinkpad X60 is not such platform. Early Athlon64 notebooks
_were_ such platforms. Can you provide example modern platform you are
talking about?

I would really like race to idle to be true for all cases, it would
simplify the kernel and we could just remove cpufreq, always running the
CPUs at max frequency. But so far I don't see Intel ignoring this
problem either, they keep developing a pstate driver which changes the
P-states based on average CPU load.

Race-to-idle is win on all modern x86 systems, because they have high
power consumption even on low non-idle frequency, due to leakage. We
still keep P-states for cooling, for completeness and for older
systems.

quoted

But it depends on the numbers you did not tell us. I'm pretty sure
N900 does _not_ have 11% power consuption at 33% performance; I just
assumed so for sake of argument.

So, really, details are needed.

If that's the only issue to be addressed, I'm happy to ignore the
frequency scaling initially and focus on idle. But since people still do
frequency scaling and this would interfere with the scheduler, we have

I guess there are modern platforms and workloads where frequency
scaling makes sense. You only need to find one, and provide numbers
for it. Please.
       	   	     	     	      	      	      	      Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html