Bug 7393 - inspiron 6000 CPU not idling efficiently
Summary: inspiron 6000 CPU not idling efficiently
Status: REJECTED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: acpi_power-processor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-20 21:31 UTC by Michael Slade
Modified: 2008-01-06 21:18 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.19-rc2 and others
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Michael Slade 2006-10-20 21:31:39 UTC
I have reason to believe that this machine is not properly minimising CPU power
consumption.  My suspicions are due to the following measurements I have taken,
by measuring the change in battery capacity (as indicated by
/proc/acpi/battery/BAT0/state) over 5 mins or so:

linux idle at 800 MHz: 27W
linux idle at 1600 MHz: 36W
linux raytracing at 800: 30W
linux raytracing at 1600: 42W

Assuming a linear frew/power relationship, this suggests that in linux, the CPU
consumes 9W when idle and 12W when running at 800MHz.  Also, according to the
"batterymon" shareware in windows XP on the same machine:

windows idle (presumably 800MHz): 16W
windows raytracing (presumably 1600MHz): 36W

This means I have about 60% of the battery life in windows as I do in linux.  On
top of this the laptop is running much hotter than it's probably designed for -
It's very hot to touch under the bottom when in linux.

I haven't yet found a kernel that doesn't have this problem.  I even tried bbc
2.1 (rescue disk) which IIRC (can't check right now) has a 2.4 kernel.

I've tried noapic and "echo n > /sys/module/processor/parameters/max_cstate",
where n is 1 thru 4.  Neither appear to have any affect.

Here are some data dumps for reference, all produced on a vanilla 2.6.19-rc2
kernel in ubuntu dapper:

http://knobbits.org/archived/2006-10/i6k-lspci.txt
 - lspci output

http://knobbits.org/archived/2006-10/i6k-acpi-cpu.txt
 - contents of /proc/acpi/processor/CPU0/*

http://knobbits.org/archived/2006-10/i6k-sys-cpu.txt
 - contents of /sys/devices/system/cpu/cpu0/cpufreq/*

http://knobbits.org/archived/2006-10/i6k-power-test.txt
 - outputs of /proc/acpi/processor/CPU0/power (almost) exactly 10s apart, with
<1% CPU usage, at 800 MHz

If someone could start by asserting that that last output does/doesn't add up,
that would help.
Comment 1 Chris Wedgwood 2006-10-20 21:46:53 UTC
I've seen similar results with a T43p Thinkpad.

That is, Windows using less power than Linux and runs cool, even when the CPU is
busy.
Comment 2 Venkatesh Pallipadi 2006-10-21 09:38:28 UTC
Yes. The last output /proc/acpi/power/*/* does look good.

Len: P-states and C-states seem to be fine here.. Any other ideas? Is it the
screen brightness or something?

Comment 3 Michael Slade 2006-10-25 02:59:26 UTC
It's not the screen brightness.  If I go "xset dpms force off" and then do
another 5min test under otherwise the same conditions as before, I get 24W.
Comment 4 Michael Slade 2006-10-25 04:39:59 UTC
So I gave in and read some of the ACPI spec :)

According to the spec, the timer used for the "duration" stats in
/proc/acpi/processor/CPU0/power runs at 10MHz.  The total of the deltas of the
numbers in the test I created add up to 3.3e6 per second, suggesting that there
are 6.7e6 ticks per second unaccounted for.  Or am I missing something?
Comment 5 Michael Slade 2006-11-27 17:32:26 UTC
The same machine exhibits some other cstate-related behavior which my hunches
tell me is related to this issue.

A bug with timing occured in an earlier kernel version that caused the CPU usage
to be misreported, and the timing of the X beep to become erratic.  This was
exasperated by entering

echo 1024 > /proc/sys/dev/rtc/max-user-freq

And was fixed by setting max_cstate to 1.  It was fixed in a later kernel.  This
, I thing, is the same bug:

https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/30557

Recently I have started using vmware and noticed it also has timing problems,
and these problems are also fixed by setting max_cstate to 1.

As stated before, however, changing max_cstate doesn't affect power consumption
noticeably.
Comment 6 Venkatesh Pallipadi 2007-11-20 14:56:08 UTC
Is this still a problem with latest base kernel?
Comment 7 Len Brown 2008-01-06 21:18:35 UTC
Michael Slade, Chris Wedgwood,
if this is still a problem with a recent version of Linux,
please run powertop http://www.lesswatts.org/projects/powertop/
report what you see, and re-open this report.

Note You need to log in before you can comment on or make changes to this bug.