Messages in this thread | | | Date | Tue, 21 Jan 2014 13:20:10 +0100 | From | Pavel Machek <> | Subject | Re: [11/11] system 1: Saving energy using DVFS |
| |
Hi!
> > > 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.
> > 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.
> > 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
| |