Brock Pytlik wrote:
Mark Haywood wrote:
Mark Haywood wrote:
Brock Pytlik wrote:
Bill Nesheim wrote:
On 04/24/09 11:55, Mark Haywood wrote:
Bill Nesheim wrote:
Detlef [email protected] wrote:
Hi,
with b111a now I can boot again my Toshiba M9.
1.I discoverred that Power Management seems no longer to work.
(The fan is blowing like hell and "kstat -m cpu_info" shows in
currentClock_Hz 2001000000
but
supported_frequencies_Hz
800000000:1200000000:1600000000:2000000000:2001000000
New Bug with b111a ?
<snip>
The current_clock_Hz is a little deceiving. The Power Aware
Dispatcher results in much more frequent P-State transitions. Try
running /usr/bin/powertop for better information.
Mark
Indeed. powertop shows the system switching nicely between 800Mhz
and 1401 Mhz), with most time spent at 800. Thanks.
-- Bill
Unfortunately, I don't see the same thing on my Tecra M10. Perhaps
I haven't twiddled the right switch to turn power management on,
but I would've expected this to have been on by default. In any
case, powertop reports that my machine's always at 2531 Mhz (more
detailed output below in case that helps).
Brock
OpenSolaris PowerTOP version
1.1
Cn Avg residency P-states (frequencies)
C0 (cpu running) (20.3%) 800 Mhz 0.0%
C1 0.5ms (79.7%) 1600 Mhz 0.0%
2530 Mhz 0.0%
2531 Mhz 100.0%
Wakeups-from-idle per second: 1715.5 interval: 5.0s
Power usage (ACPI estimate): 0.000W (running on AC power,
fully charged)
Top causes for wakeups:
20.7% (354.7) <kernel> : genunix`cv_wakeup
9.7% (166.8) <interrupt> : audiohd#0
7.5% (129.4) sched : <cross calls>
5.8% (100.2) <kernel> : genunix`clock
2.4% ( 41.8) <interrupt> : iwh#0
1.4% ( 23.2) <kernel> :
uhci`uhci_handle_root_hub_status_change
0.8% ( 14.4) <interrupt> : i8042#0
0.8% ( 13.6) firefox-bin : <cross calls>
0.6% ( 10.0) <kernel> : genunix`delay_wakeup
0.5% ( 8.2) gnome-netstatus- : <cross calls>
0.5% ( 7.8) <kernel> :
ehci`ehci_handle_root_hub_status_change
0.3% ( 6.0) <kernel> : uhci`uhci_cmd_timeout_hdlr
0.3% ( 4.4) <kernel> : genunix`lwp_timer_timeout
0.2% ( 4.0) <kernel> : genunix`schedpaging
0.1% ( 2.0) <kernel> : cpudrv`cpudrv_monitor_disp
0.1% ( 1.8) <interrupt> : e1000g#0
0.1% ( 1.2) <kernel> :
sd`sd_pm_idletimeout_handler
0.1% ( 1.0) <kernel> : nvidia`nvidia_rc_timer
Your idle system looks a lot more busy than mine. I'm spending
almost 90% of my time in C1 while you are almost 80%. Eric knows
the intimate details of how the dispatcher determines to change
P-States, so maybe he can explain.
In the meantime, you *might* get better power savings in poll mode.
Just change
cpudrv enable
to
cpudrv enable poll-mode
Sorry, make that "cpupm" instead of '"cpudrv" above.
Thanks, that made a huge difference. I'm now spending about 65-70% of
time in C1 (down from 80%), but now I'm seeing my P-states change
instead of being pegged at 2531Mhz. When I'm essentially idling, I'm @
800Mhz, and popping up to higher P states periodically.
That seems like a lot of time to be spending in C0. Is your system
supposed to be essentially idle? I see a lot of wakeups due to audiohd?
One other thing I'm noticing that seems suspicious is that my
percentage is always at 100% for one P state. It seems somewhat
unlikely (to me at least) that it's changing P states exactly on every
5 second interval that powertop's using to sample. Is it possible that
the percentage isn't doing quite what's expected?
This doesn't surprise me all that much. In poll-mode the P-State
transitions are much less frequent. You probably won't see them change
often at all unless you either go from being idle to pretty busy or from
busy to idle. In event-mode you should see transitions many times a
second even on a somewhat idle system.
Mark
Brock
in /etc/power.conf and run /usr/sbin/pmconfig.
Mark
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
