LWN: Comments on "Observations on power management"

Observations on power management

MKesper — Mon, 01 Dec 2008 08:26:49 +0000

As soon as I lock the screen, the background light should turn dark.
Besides, my netbook uses a LED backlight so I don't have to care about dying cathodes. :-)

Observations on (OMAP) power management

HalfMoon — Mon, 01 Dec 2008 03:57:22 +0000

OMAP processors come from cell phone designs, so they're pretty far ahead of what mainstream x86 processors -- or even SOCs -- do. They've got to stretch leetle tiny batteries out to a week of use. Accordingly they're pretty far ahead of most other embedded processors in terms of being optimized for low power consumptions.

One big hangup for Linux is that so much of the power management work has been revolving around ACPI ... which has a lot of fairly broken concepts in those very low power concepts. One of the biggest being that it even makes *sense* to need separate system states like "suspend to memory". Those OMAP designs more or less aim at having that be the default system idle state.

This isn't entirely unlike the OLPC model ... except OLPC was stuck with hardware designed to fit into an ACPI world, and which accordingly doesn't have good support for all that runtime power management. Devices tend to need long delays to get back to runnable states. The system doesn't really resume into a low power state, it resumes into a full power state and then -- if you're lucky! -- all the devices (and bridges etc) go into low power states right away

It'll take a long time for x86 system design methodologies to adapt to the models used in OMAP. If they even can. Intel's ATOM stuff isn't aiming to be that power-efficient, and I can't think of any other companies in the x86 space who have the technical and market power to change the game that much.

Observations on power management

linusw — Thu, 27 Nov 2008 21:11:57 +0000

I already mailed the following remark to Matthew and just reposting here because there might be common interest:

I get the sense that this is for common Intel-like ACPI-controlled
components, but have you seen the stuff Texas Instruments implemented in
the OMAP3430 embedded processor? I attended a demo of this at the CELF
embedded Linux conference in april and it was quite impressive, there is
a presentation here (powerpoint, not my fault):
http://www.celinux.org/elc08_presentations/TI_OMAP3430_Li...

Page 19 is especially interesting: they have implemented C-states,
however these have platform-specific meanings:

C0 System executing code
C1 MPU WFI + Core active + No tick suppression
C2 MPU WFI + Core active + Tick suppression
C3 MPU CSWR + Core active + Tick suppression
C4 MPU OFF + Core active + Tick suppression
C5 MPU RET + Core RET + Tick suppression
C6 MPU OFF + Core RET + Tick suppression
C7 MPU OFF + Core OFF + Tick suppression

OFF is really OFF as in power disconnected. So this is how they address
submicron technologies with increased leakage.

On top of that all peripherals are already powered down when not used
(even for very very short intervals, ms range) this is called "OFF
mode".

This is so far ahead of anything I've seen on the desktop, laptop etc,
so I think it's interesting because that's where I think the common
equipment must be in just a few years.

Taking a stand

tialaramex — Thu, 27 Nov 2008 17:30:25 +0000

My understanding is that this problem is in Mono, specifically, rather than being related to .NET per se.

Your situation is unfortunate but probably unrelated.

Observations on power management

lysse — Thu, 27 Nov 2008 12:30:12 +0000

Contrast is a friend for those of us with dodgy eyesight.

I miss monochrome monitors; I don't suppose they're made any more, are they? A shame; I'd love to have a 600dpi monochrome A3-sized TFT on my desk - and given that 225dpi colour displays can be made, I think it's possible...

Taking a stand

ncm — Thu, 27 Nov 2008 04:52:36 +0000

If to be a C programmer is to be a stick in the mud, then to be a C++ programmer is to stick a bee in the mud.

Ad Hominem

BenHutchings — Wed, 26 Nov 2008 23:34:45 +0000

Much useful information can be found at http://angryfacts.com/

Taking a stand

ebirdie — Wed, 26 Nov 2008 20:40:02 +0000

I have been hosting a Windows Server 2003 system running as a virtual machine on KVM. On the Windows system is run a .NET app with mysql backend. The .NET app is said to use threads heavily. The .NET app is having problems handling service requests in https. It is slow and drops connections even with minor load. The problem I have with it is that the developers of the app say that I am using a crappy Open Source virtual machine and not some "professional tool" like HyperV or VMware. :-)

Can anyone say here, could the above, what tialaramex described, have effects on KVM too ie. although there is a Windows system doing the threading and signaling "the right way", the VM hosting Linux kernel could have effect to native .NET runtime? Should I quote these comments from here and ask the same on KVM-devel list?

OLED?

dmarti — Wed, 26 Nov 2008 15:39:15 +0000

I'm saving up for an OLED monitor when those come out (the TV at the Sony store is beautiful). OLED doesn't have a backlight and AFAIK black is off.

Taking a stand

Los__D — Wed, 26 Nov 2008 09:15:20 +0000

Doh, that's what I get for taking time to check something, only to use a few seconds writing... :)

It was around 2 wakeups/second.

I don't know the cause, but let's see if they don't get it fixed.

Taking a stand

tialaramex — Wed, 26 Nov 2008 08:58:09 +0000

Well, a typo seems to have slipped into your comment, eliminating the key figure you were trying to communicate. But assuming it's a very small number, rather than say 10 which would just confirm what I said...

It's likely that this bug only affects Mono programs which use threads and can handle signals (merely dying when sent a signal doesn't require "handling") since the usual problem (seen and fixed in e.g. Python) seems to be that someone couldn't figure out how to reconcile POSIX signals with some Windows inspired threading in their design and resolved to just "poll" for signals. Personally I wouldn't have any confidence in a language runtime built by people who couldn't figure out the Right Thing but then I'm a C programmer so perhaps I'm just being a stick in the mud.

Observations on power management

ncm — Tue, 25 Nov 2008 21:50:34 +0000

Turning down the brightness of the white background saves your eyes and saves power, too.

Observations on power management

saffroy — Tue, 25 Nov 2008 16:32:38 +0000

powertop would be "too geeky"? I would rather say "not geeky enough", considering that the article mentions disk seeks and mount options, but not laptop mode, for instance.

BTW powertop gives some interesting advice, eg. "enable laptop mode" or "use a kernel with NOHZ".

Backlights

sladen — Tue, 25 Nov 2008 15:30:42 +0000

The digital watch you're describing is using a simple LCD display (not a VFD/TFT/LED). If you were to flip the polarising glass over on the watch (more easily done on a household/school calculator) then you will have a display that default to black, with clear (reflected) writing.

In a self-illuminated colour TFT display, the bright white backlight is used as a starting point, and selectively blocked out (meaning "black" never looks quite black). Transreflective screens complement the blacklight with reflected incoming light (as with the digital watch/calculator's primary source).

Finally, high-end recent flat-screen displays are now are able to selectively shut-off/tone down the output of the backlight in areas where the image is dark or black; by avoiding producing extra light in the first place, less of that light needs blocking to produce a satisfying black.

Observations on power management

nix — Tue, 25 Nov 2008 13:48:49 +0000

Black text on a white background hurts my eyes (not surprising given that that means I'm basically staring into a light bulb).

Observations on power management

renox — Tue, 25 Nov 2008 13:14:02 +0000

I disagree with you here: this doesn't make sense for the computer, but it make sense for the user.

If the user stays too long with doing anything the screen will idle to black and then the backlight will be disabled: it make sense to have an idle screen as quite often the user will move the mouse to re-activate it.

Should the idle screen be white or black?
There's a power usage reason for it to be white for LCD, but there's also a 'do not distract the user' reason to use black as when the backlight will be disabled the user won't notice an annoying white to black flickering.

Taking a stand

Los__D — Tue, 25 Nov 2008 12:53:50 +0000

Ehm, my powertop seems to mark Tomboy (also uses the Mono runtime) as having around wakeups per second, and that is only when the window is visible (GTK# repainting needlessly maybe?).

It would seem like this is primarily an issue with Beagle, or that the Tomboy developers has found a way to eliminate the problem.

- Or that I'm on crack and reading the PowerTop output wrong?

Wrong CPU!

niner — Tue, 25 Nov 2008 11:30:26 +0000

What you describe is SpeedStep, which is available in Pentium M and Core CPUs. The
article talked about p4-clockmod, which handles Pentium 4 and Pentium 4-M CPUs,
which _do not_ alter the voltages.

Taking a stand

pharm — Tue, 25 Nov 2008 10:38:05 +0000

Ubuntu moved to tracker for their indexing system IIRC

Observations on power management

Richard_J_Neill — Tue, 25 Nov 2008 04:28:52 +0000

> For instance, Ubuntu by default still blacks out the screen for several
> minutes before disabling the backlight, as if this made any type of sense
> for today's computers.

Actually, this isn't as daft as it sounds. Apart from the disk, the LCD is the most likely thing to fail in a laptop - whether the backlight dies totally, or just dims or "yellows" over time. CCFL backlight life is hurt by both runtime and number of start-cycles. So, unless battery life is really really at a premium, you want to avoid turning off the backlight when the user is still actually using the machine.

Taking a stand

tialaramex — Tue, 25 Nov 2008 04:23:35 +0000

Some of what needs to happen on issues like this is just a Debian-style stand on principle to eliminate problems even if this is briefly painful.

Beagle for example, survived early culls of awful software after Powertop by claiming that "soon" the Mono runtime would be fixed to eliminate its hopeless per-process (per-thread?) 10Hz timer that runs day & night, idle or busy. And once it had survived a few months this way, any feeling of urgency or even the vague idea that someone ought to /fix/ it went away, so here we are in November 2008, with people talking about the 2009 Linux distributions on the horizon, and not one of them seems to have "rip out Mono due to whale-murdering / wallet-emptying runtime" on its TODO list despite most of them talking about the importance of laptops & netbooks.

Observations on power management

ncm — Tue, 25 Nov 2008 03:17:46 +0000

Yet another argument for defaulting to black text on a white background: it doesn't just save your eyes, it saves power.

Ad Hominem

nix — Tue, 25 Nov 2008 01:35:55 +0000

Cambridge. It's the Chiark effect: the Ian Jackson hackish field.

Or something like that, anyway.

Observations on power management

sbergman27 — Tue, 25 Nov 2008 01:21:50 +0000

Yep. My 22" measures 26 watts while white and 27 watts while black. (My kill-a-watt only displays in increments of 1 watt.) I had always thought it would be the other way around. But now that I think about it, when a watch battery dies, the display turns all silver and not all black. It takes power to make black.

Ad Hominem

felixfix — Tue, 25 Nov 2008 00:41:57 +0000

Inebriated, presumably.

Observations on power management

JoeBuck — Tue, 25 Nov 2008 00:40:11 +0000

Your formula describes dynamic power from CMOS switching, assuming that everything operates on the same clock. However, these days leakage power is a major issue and can be as large as dynamic power.

Since leakage power (roughly speaking) is linear in the voltage and isn't affected by the clock frequency, and since leakage power can be turned off by turning major hunks of the chip off, this tends to make it more effective to "race to idle" and turn the chip off than to voltage-scale. For some small embedded RISC processors the tradeoffs are different.

Ad Hominem

ncm — Tue, 25 Nov 2008 00:22:34 +0000

Well, yes, but what kind of whiskeyed fruit flies?

Ad Hominem

sladen — Mon, 24 Nov 2008 23:07:02 +0000

Whisky and Fruit flies. I think.

Ad Hominem

ncm — Mon, 24 Nov 2008 21:42:33 +0000

It's time for an ad hominem remark: Matthew Garrett rocks. We need more of him. Fortunately, he was constructed in his present form in well under 30 years, so the lead time to construct a whole army of Matthews -- were the secret to his construction known -- is short enough not to be prohibitive.

Biographical information, please, with emphasis on formative educational processes?

Observations on power management

nix — Mon, 24 Nov 2008 21:07:41 +0000

Of course this only applies if you're displaying a screensaver image. If,
say, you're display an xterm (almost totally black, a bit of white text),
turning off the backlight is a rather bad idea, and you just have to eat
that tiny extra bit of power.

Observations on power management

jwb — Mon, 24 Nov 2008 20:33:53 +0000

Yes, absolutely I agree. I was just trying to underscore the stupidity of the current batch of black screen "savers". For instance, Ubuntu by default still blacks out the screen for several minutes before disabling the backlight, as if this made any type of sense for today's computers.

Observations on power management

pebolle — Mon, 24 Nov 2008 20:31:44 +0000

"It would be better to simply turn off the backlight."

Isn't that just what the author suggests: "Summary: If the user has not requested an animated screensaver, turn the screen off immediately rather than drawing a black screen."?

Observations on power management

jwb — Mon, 24 Nov 2008 20:27:44 +0000

Here, let me google that for you:

http://techlogg.com/content/view/317/
http://www.g4techtv.ca/callforhelp/shownotes/0283.shtml?r...

And I've measured my own monitor as well. If you think about how an LCD works, it's logical that 100% black requires the highest current consumption in the panel.

Observations on power management

MattPerry — Mon, 24 Nov 2008 20:17:38 +0000

Can you provide a source to support that statement?

Observations on power management

mjg59 — Mon, 24 Nov 2008 19:44:45 +0000

Theoretically. In reality, the benefits aren't nearly that great. See Intel's figures at http://www.lesswatts.org/projects/applications-power-mana... , for instance.

Observations on power management

alecs1 — Mon, 24 Nov 2008 19:15:55 +0000

I think this has already been discussed here, but making the frequency go down can bring smaller voltages, and Matthew Garrett seems to be aware of it.

Wikipedia on SpeedStep:
"P = C(V^2)f
[...] For example, for a 1.6 GHz Pentium M, the clock frequency can be stepped in 200 MHz increments over the range from 1.6 to 0.6 GHz. At the same time, the voltage requirement decreases from 1.484 V to 0.956 V. The result is that the power consumption theoretically goes down by a factor 6.4.".
The article goes on an aknoledges that this is only a teoretical computation.

Also, running at smaller frequencies may prevent the fans from spinning up, but I don't know how important that is.

Until I see benchmarks, I can't fully trust these CPU claims.

Observations on power management

roblatham — Mon, 24 Nov 2008 19:09:32 +0000

I'm surprised there was no mention of powertop... is that considered too geeky?

==rob

Observations on power management

jwb — Mon, 24 Nov 2008 18:47:47 +0000

"A black screen takes up as much power on a TFT as a white one."

Almost true. A black image actually takes measurably more power than a white one on an LCD display. Black is the worst power state for a flat panel display. It would be better to simply turn off the backlight.

Observations on power management

tajyrink — Mon, 24 Nov 2008 18:38:44 +0000

Some little extra observations:

"Don't offer the choice of disabling compositing when on battery. It reduces functionality for no power benefit."

This one only becomes true with 2.6.28 or so, when all the vblank fixes in the drm drivers (intel and ati mainly) are in. Before it, it seems that composite/3D desktop triggers an amount of wakeups per second that equals the refresh rate, regardless of idleness. It's been fixed in drm trunk for over a year, but only with 2.6.28 the backlog started to really flow into Linus' kernel (I think. At least GEM went in.).

"Seeking takes more power than simply reading a linear set of blocks off a drive. It also kills performance - even a high spec drive will be unlikely to be able to perform more than 150 seeks a second."

I hope everyone developing eg. anything related to X, Compiz, KDE or GNOME startup reads this... otherwise we'll be stuck with the current boot+login time problems for the next 5-10 years until every root filesystem drive has been replaced with an SSD drive.