| Author |
Message |
|
|
Post subject: Powertop Kernel Recommendations
 Posted: Aug 11, 2007 - 03:14 AM
|
|
Joined: Dec 01, 2006
Posts: 906
Status: Online!
|
|
As
most of you know, there has been efforts to make the linux kernel more
power efficient. Intel wrote an application called powertop to find
what applications are waking up your cpu the most when it is supposed
to be idle.
They have a site at linuxpowertop.org and have recommendations on
what kernel options should be changed. So, of course, I was wondering
if some of these that are not already configured could be
enabled/disabled.
source: http://linuxpowertop.org/faq.php
What kernel options should I enable inside the kernel?
CONFIG_NO_HZ
CONFIG_HIGH_RES_TIMERS
CONFIG_HPET_TIMER
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_USB_SUSPEND
CONFIG_SND_AC97_POWER_SAVE
CONFIG_TIMER_STATS #this is to allow powertop to make statistics on what applications are causing the most wake ups and what not
What kernel options should I disable inside the kernel?
CONFIG_IRQBALANCE
CONFIG_ACPI_DEBUG
Some of these are also suggestions while running the application. |
|
|
| |
|
|
|
 |
|
|
|
Post subject: RE: Powertop Kernel Recommendations
Posted: Aug 26, 2009 - 01:48 AM
|
|
Joined: Aug 26, 2009
Posts: 1
Status: Offline
|
|
| I agree with damentz. Could sidux have these options adopted so we can use powertop and optimize laptop energy use? |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Powertop Kernel Recommendations
Posted: Aug 29, 2009 - 11:40 AM
|
|
Joined: Jan 10, 2008
Posts: 680
Status: Offline
|
|
I don't agree:
Playing and tuning with the kernel is special. Everybody who wants
to do that should be able to compile his own kernel. Any config
(CONFIG_TIMER_STATS) which reduces performance or is a potential risk
of functionality for the end user is not wanted in general.
By the way some configs of above are set by slh!
Using htop you are able to identify any resource hungry application (sort by process time!). |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Powertop Kernel Recommendations
Posted: Sep 05, 2009 - 07:38 PM
|
|
Joined: Sep 05, 2009
Posts: 1
Status: Offline
|
|
|
ralul wrote:
I don't agree:
Playing and tuning with the kernel is special. Everybody who wants
to do that should be able to compile his own kernel. Any config
(CONFIG_TIMER_STATS) which reduces performance or is a potential risk
of functionality for the end user is not wanted in general.
It might not be THE argument, but most distros I know got these
features enabled, because all Laptop-users who hear from powertop want
to use it (and you know how impatient new linux users are). If there is
a performance penalty, it would be less than 1% I guess. Given the
useful recommendations for powersaving => they DO work, I have
tested it a year ago: http://www.linuxhome.ch/news/thinkpad-x ... r-10-watt/ (only in German sorry).
I'd give it a try, we're not talking about adopting Reiser4 or Con's brainfuck scheduler here 
Greetings
Chris |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Powertop Kernel Recommendations
Posted: Sep 05, 2009 - 08:15 PM
|
|
Joined: Jan 10, 2008
Posts: 680
Status: Offline
|
|
A hundred of tiny features which have a 0.5 percentage load:
it is a half loaded machine.
[edit] This was not meant very serious, I should have put a |
Last edited by ralul on Sep 06, 2009 - 04:57 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Powertop Kernel Recommendations
Posted: Sep 06, 2009 - 08:16 AM
|
|
Joined: Dec 01, 2006
Posts: 906
Status: Online!
|
|
It is foolish to assume a feature reduces throughput by 0.5 percent without benchmarking it.
Because you are unable to do research: timer statistics are opt in, enabled when an application requests it (powertop), or when done manually.
You can't tell me that you expect to use this feature 24/7 to prove my
point that your computer runs slower, that's mean and not considered
typical desktop usage.
If you need this feature, there are alternative kernels that are easy to find which may prove to be more useful in the long run. |
_________________
"Cool was never cool until the cool guys at Cool industries developed a cool new product: Cool."
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Powertop Kernel Recommendations
Posted: Sep 06, 2009 - 10:01 AM
|
|
Team Member
Joined: Nov 24, 2006
w3
Posts: 3042
Status: Offline
|
|
Once
every 3 months damentz re-starts this discussion (because he does not
use sidux kernels but his own ones, anyway), while he is of course
aware already of the reasons why sidux kernels will not activate it.
For those interested in the topic, please search the forum for
powertop, one of the latest clear statements from slh can be found here and is still valid.
Greetings,
Chris |
_________________
an operating system must operate - sidux.com
development is life - code.zikula.org
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 07, 2009 - 05:36 AM
|
|
Joined: Dec 01, 2006
Posts: 906
Status: Online!
|
|
The
conclusion for CONFIG_TIMER_STATS is invalid for no quantitative
evidence and absence of any reference to the claim of "increasing"
power usage.
Code:
timer_stats is a debugging facility to make the timer (ab)usage in a Linux
system visible to kernel and userspace developers. If enabled in the config
but not used it has almost zero runtime overhead, and a relatively small
data structure overhead. Even if collection is enabled runtime all the
locking is per-CPU and lookup is hashed.
and
Code:
The timer_stats functionality is inactive on bootup.
To activate a sample period issue:
# echo 1 >/proc/timer_stats
To stop a sample period issue:
# echo 0 >/proc/timer_stats
The statistics can be retrieved by:
# cat /proc/timer_stats
As far as I'm concerned and as long as the documentation clearly states that there is no problem, slh's conclusion is still invalid and will continue to be so.
Quote: Once
every 3 months damentz re-starts this discussion (because he does not
use sidux kernels but his own ones, anyway), while he is of course
aware already of the reasons why sidux kernels will not activate it.
You could have clipped your toe nails and ordered a nice large deep
dish pizza in the time it took you to come up with that one, what are
you doing? |
_________________
"Cool was never cool until the cool guys at Cool industries developed a cool new product: Cool."
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Powertop Kernel Recommendations
Posted: Sep 07, 2009 - 12:53 PM
|
|
Joined: Jan 10, 2008
Posts: 680
Status: Offline
|
|
|
slam wrote:
clear statements from slh can be found here and is still valid.
damentz seems to be right, he is not proposing usb_suspend...
damentz, how to interpret such a list:
Code:
Timer Stats Version: v0.2
Sample period: 161.028 s
179, 8065 konsole hrtimer_start_range_ns (hrtimer_wakeup)
3220, 0 swapper hrtimer_start_range_ns (tick_sched_timer)
2016D, 16 kondemand/0 do_dbs_timer (delayed_work_timer_fn)
161, 8265 bash queue_delayed_work (delayed_work_timer_fn)
1, 8065 konsole cfq_completed_request (cfq_idle_slice_timer)
652, 0 swapper hrtimer_start (tick_sched_timer)
241, 2057 dirmngr hrtimer_start_range_ns (hrtimer_wakeup)
98, 2729 Xorg hrtimer_start_range_ns (hrtimer_wakeup)
643, 0 swapper usb_hcd_poll_rh_status (rh_timer_func)
643, 0 swapper usb_hcd_poll_rh_status (rh_timer_func)
167, 8016 kwin hrtimer_start_range_ns (hrtimer_wakeup)
|
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Powertop Kernel Recommendations
Posted: Sep 10, 2009 - 05:56 AM
|
|
Joined: Dec 01, 2006
Posts: 906
Status: Online!
|
|
|
Quote:
damentz, how to interpret such a list
Like most raw data, it's easier to let an application parse it -
Powertop; it does the math, sorting, colors, magic... all for you.
You can't with slh's kernel.
example:
Code:
PowerTOP version 1.11 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) (17.7%) 2.21 Ghz 0.8%
polling 0.0ms ( 0.0%) 1.60 Ghz 0.0%
C1 mwait 0.0ms ( 0.0%) 1200 Mhz 0.5%
C2 mwait 0.1ms ( 0.2%) 800 Mhz 98.7%
C4 mwait 0.8ms (82.2%)
Wakeups-from-idle per second : 1042.9 interval: 5.0s
no ACPI power usage estimate available
Top causes for wakeups:
48.9% (662.8) <kernel IPI> : Rescheduling interrupts
27.7% (375.2) <interrupt> : uhci_hcd:usb4, uhci_hcd:usb6, HDA Intel
7.5% (101.4) firefox-bin : schedule_hrtimeout_range (hrtimer_wakeup)
7.5% (101.0) <interrupt> : extra timer interrupt
2.3% ( 31.4) firefox-bin : futex_wait_queue_me (hrtimer_wakeup)
2.3% ( 30.8) <interrupt> : iwl3945
1.1% ( 15.2) xchat : schedule_hrtimeout_range (hrtimer_wakeup)
0.7% ( 10.0) gnome-settings- : schedule_hrtimeout_range (hrtimer_wakeup)
0.6% ( 8.4) <interrupt> : ata_piix
0.3% ( 3.8) ksoftirqd/0 : usb_hcd_poll_rh_status (rh_timer_func)
0.3% ( 3.4) xchat : do_nanosleep (hrtimer_wakeup)
0.1% ( 2.0) gnome-terminal : schedule_hrtimeout_range (hrtimer_wakeup)
0.1% ( 1.8) multiload-apple : schedule_hrtimeout_range (hrtimer_wakeup)
0.1% ( 1.0) <interrupt> : nvidia
0.1% ( 0.8) <interrupt> : ahci
0.1% ( 0.8) cpufreq-applet : schedule_hrtimeout_range (hrtimer_wakeup)
0.1% ( 0.8) <kernel core> : tg3_timer (tg3_timer)
0.1% ( 0.8) <kernel core> : run_timer_softirq (nv_kern_rc_timer)
That's the effect of playing audio with a period size of 128 in
alsa (very low latency). The actual media player doesn't show up on the
list since the processing it needs to do is minimal. However, the sound
card does, HDA Intel. |
_________________
"Cool was never cool until the cool guys at Cool industries developed a cool new product: Cool."
|
 |
|
|
|
|
|
|
