You are not logged in.
I changed by script a little bit. Now it does not use xbacklight because it only sets backlight of one of my screen.
for i in /sys/class/backlight/acpi_video*/brightness; do echo 2 > $i; done
aspm and rc6 are included in my script.
"After you do enough distro research, you will choose Arch."
Offline
irqbalance also saves up some power and is good for overall performance (available in [extra] ). there's already an interrupt balancing technique implemented in the kernel but it's a bit rudimentary and not recommend to use.
"Use the interrupt (IRQ) balancing technique to distribute the various interrupts, from the devices on the system, over the cores/processors in the system. "
Offline
I went ahead and looked up irqbalance and it seems like a cool idea, but all the stuff I see is referring to pretty old kernel versions. Does the kernel still not do a good enough job of balancing irqs even though pretty much everyone has smp processors now?
Offline
@op- Some of your powersaving tweaks causes both touchpads and usb mice to stop responding. Suggest you update removing them.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
1. i915 will stop rendering properly once in deep sleep mode, so i915 is removed at the moment
2. @graysky
usb does not stop responding. The are in autosuspend once not used for 1 sec. click right or left button to start it again.
to disable powersave, replugin the usb mouse.
3. @pogeymanz
yeah. thats what i am thinking. the other point is that smt,mc_power_policy works because they move more processes to active cpus, and turn off( or put in idle) for unused ones.
i feel that irq will distribute the work on all cpus, so they will not have a chance to stay in idle mode.
"After you do enough distro research, you will choose Arch."
Offline
@taylorchu - at least comment that line in your script as options with your advice as to how to re-enable. On my laptop, clicking left/right does nothing and the touchpad is completely frozen until a reboot.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
I have another one
for i in $(ls /sys/bus/usb/devices/*/power/level);do echo auto > $i;done
This is a depreciated method, if you run this you will get a warning to use control, at least does on 3.2 for me
for i in $(ls /sys/bus/usb/devices/*/power/control);do echo auto > $i;done
Works for me but does not spit out an error
edit: spelling
Last edited by vwyodajl (2012-01-25 12:01:45)
Offline
@taylorchu - at least comment that line in your script as options with your advice as to how to re-enable. On my laptop, clicking left/right does nothing and the touchpad is completely frozen until a reboot.
Exactly why I posted this:
Additional information about what each option does and how it can effect usage would also be welcome.
(e.g. NMI Watchdog)
(e.g.#Enabling the controller can produce "clicking" noises when the device wakes up echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller
)
Edit: I believe most of this has been covered already but here's some nice ideas from Red Hat
At least inform people as to how each option can potentially effect their system.
(Unless you don't know... (because, I don't without looking through documentation))
Last edited by Earnestly (2012-01-25 13:15:45)
Offline
Hey! This looks pretty nice.. If possible can you provide some more information (I'm still a bit out where to put your script, like in /etc/pm/power.d..?) and how do you execute it. Thanks.
EDIT1. Modified your script a bit, it seems to work when I put it in "/etc/rc.local".. hope it's not dangerous
Last edited by Shinryuu (2012-01-25 23:07:46)
Offline
@Shinryuu
you can put it in /etc/pm/power.d if you want to switch between the settings, depending on the AC state.
Here is one example:
[/home/robert]$ cat /etc/pm/power.d/00powersave
#!/bin/sh
# A script to enable laptop power saving features for #! & Debian GNU+linux.
# http://crunchbanglinux.org/forums/topic/11954
# List of modules to unload, space seperated. Edit depending on your hardware and preferences.
modlist=""
# Bus list for runtime pm. Probably shouldn't touch this.
buslist="pci spi i2c"
case "$1" in
true)
logger "launch powersave, laptop is not on AC"
# Enable some power saving settings while on battery
# Set governor to powersave level for both CPUs
echo "powersave" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "powersave" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
# aspm
echo powersave > /sys/module/pcie_aspm/parameters/policy
# Disable nmi watchdog
echo 0 > /proc/sys/kernel/nmi_watchdog
# Disk write mode
echo 5 > /proc/sys/vm/laptop_mode
echo 90 > /proc/sys/vm/dirty_ratio
echo 1 > /proc/sys/vm/dirty_background_ratio
echo 60000 > /proc/sys/vm/dirty_writeback_centisecs
mount -o remount,noatime,commit=600 /
# BUS powersave
for i in /sys/bus/{pci,spi,i2c}/devices/*/power/control; do echo auto > $i; done
# USB powersave
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
for i in /sys/bus/usb/devices/*/power/control; do echo auto > $i; done
# SATA powersave
for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo min_power > $i; done
# readahead
for dev in /dev/sd[a-z]; do blockdev --setra 3072 $dev; done
# Disk spindown
for dev in /dev/sd[a-z]; do hdparm -S 6 -B 1 $dev; done
# Sound card powersave
echo 1 > /sys/module/snd_hda_intel/parameters/power_save
echo Y > /sys/module/snd_hda_intel/parameters/power_save_controller
echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
# Disable webcam
modprobe -r uvcvideo
# Disable bluetooth
modprobe -r btusb
modprobe -r bluetooth
# wlan0/eth0 powersave
iwconfig wlan0 power on
ethtool -s wlan0 wol d
ethtool -s eth0 wol d
# Screen powersave
for i in /sys/class/backlight/*/brightness; do echo 2 > $i; done
# i915
echo 1 > /sys/module/i915/parameters/i915_enable_rc6
echo 1 > /sys/module/i915/parameters/i915_enable_fbc
;;
false)
logger "launch powersave, laptop is on AC"
# Return settings to default on AC power
# Set governor to performance level for both CPUs
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
# aspm
echo performance > /sys/module/pcie_aspm/parameters/policy
# Enable nmi watchdog
echo 1 > /proc/sys/kernel/nmi_watchdog
# Disk write mode
echo 0 > /proc/sys/vm/laptop_mode
echo 10 > /proc/sys/vm/dirty_ratio
echo 5 > /proc/sys/vm/dirty_background_ratio
echo 500 > /proc/sys/vm/dirty_writeback_centisecs
# BUS performance
for i in /sys/bus/{pci,spi,i2c}/devices/*/power/control; do echo on > $i; done
# USB performance
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 2 > $i; done
for i in /sys/bus/usb/devices/*/power/control; do echo auto > $i; done
# SATA performance
for i in /sys/class/scsi_host/host*/link_power_management_policy; do echo max_performance > $i; done
# readahead
# Disk spindown
# Sound card performance
echo 0 > /sys/module/snd_hda_intel/parameters/power_save
echo N > /sys/module/snd_hda_intel/parameters/power_save_controller
echo 0 > /sys/module/snd_ac97_codec/parameters/power_save
# Enable webcam
modprobe uvcvideo
# Enable bluetooth
modprobe btusb
modprobe bluetooth
# wlan0/eth0 performance
# Screen performance
for i in /sys/class/backlight/*/brightness; do echo 15 > $i; done
# i915
echo 0 > /sys/module/i915/parameters/i915_enable_rc6
echo 0 > /sys/module/i915/parameters/i915_enable_fbc
# Other power management settings
for i in /sys/bus/usb/devices/*/power/autosuspend; do
echo 2 > $i
done
for mod in $modlist; do
if ! lsmod | grep $mod; then
modprobe $mod 2>/dev/null
fi
done
for bus in $buslist; do
for i in /sys/bus/$bus/devices/*/power/control; do
echo on > $i
done
done
;;
esac
exit 0
Regards
Offline
yes, this could go to rc.local. I have been experimenting with more kernel param.
i might put the 2012-01-28's work to archwiki tomorrow.
"After you do enough distro research, you will choose Arch."
Offline
Kindly make sure you add explanations or links to various documentation for each parameter. (I'd personally appreciate that.)
Offline
why not put it on github? create a pkg?
imo the script should gather information first and then apply changes on the hardware ("sensors-detect" acts like that).
let the script firstly check if there's any hardware which can be adjusted by other settings to save power (auto, rfkill, unload modules, variable factor) or not.
let the user decide by a simple yes/no/integer question, provide some info on the setting (what it does, recommendable or not!?) and then save it as configuration file (nice would be a possibility to create more configs to quickly change settings and jump from one to another --> battery, ac, ultimatepowersave, ...)
Offline
@broken pipe: that sounds tasty
Offline
why not put it on github? create a pkg?
imo the script should gather information first and then apply changes on the hardware ("sensors-detect" acts like that).
let the script firstly check if there's any hardware which can be adjusted by other settings to save power (auto, rfkill, unload modules, variable factor) or not.
let the user decide by a simple yes/no/integer question, provide some info on the setting (what it does, recommendable or not!?) and then save it as configuration file (nice would be a possibility to create more configs to quickly change settings and jump from one to another --> battery, ac, ultimatepowersave, ...)
Good idea, couldn't agree more regardless of the additional complexity.
(e.g.
# Disk spindown
Warning: The Western Digital Green Series provides a feature called IntelliPark, causing the heads to be parked automatically after 8 seconds of inactivity. If the drive is used for bulk storage, the noatime and nodiratime settings above should be sufficient to prevent unnecessary access. If the drive holds the log files or MySQL backing, it will be frequently spun up and down, which causes unnecessary wear and can lead to premature failure. This problem can not be addressed with hdparm -S command due to the proprietary nature of this feature.
meaning, this command:
for dev in /dev/sd[a-z]; do hdparm -S 6 -B 1 $dev; done
might even be dangerous.)
(Or, a more positive example:
______________________________________________________________________________+
ASPM POWERSAVING|
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯'
> PCI Express ASPM defines a protocol for PCI Express components in the D0
state to reduce Link power by placing their Links into a low power state
and instructing the other end of the Link to do likewise. This
capability allows hardware-autonomous, dynamic Link power reduction
beyond what is achievable by software-only controlled power management.
However, The device should be configured by software appropriately.
Enabling ASPM will save power, but will introduce device latency.
This patch adds ASPM support in Linux. It introduces a global policy for
ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control
it. The interface can be used as a boot option too. Currently we have
below setting:
> default
BIOS default setting.
> powersave
Highest power saving mode, enable all available ASPM state and clock
power management.
> performance
Highest performance, disable ASPM and clock power management.
By default, the 'default' policy is used currently.
In my test, power difference between powersave mode and performance mode
is about 1.3w in a system with 3 PCIE links.
> 'echo powersave > /sys/module/pcie_aspm/parameters/policy'? [Y/N]:
)
Last edited by Earnestly (2012-01-27 15:42:43)
Offline
yes, this could go to rc.local. I have been experimenting with more kernel param.
i might put the 2012-01-28's work to archwiki tomorrow.
Where is this script on the wiki?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Online
(Or, a more positive example:
______________________________________________________________________________+ ASPM POWERSAVING| ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯' > PCI Express ASPM defines a protocol for PCI Express components in the D0 state to reduce Link power by placing their Links into a low power state and instructing the other end of the Link to do likewise. This capability allows hardware-autonomous, dynamic Link power reduction beyond what is achievable by software-only controlled power management. However, The device should be configured by software appropriately. Enabling ASPM will save power, but will introduce device latency. This patch adds ASPM support in Linux. It introduces a global policy for ASPM, a sysfs file /sys/module/pcie_aspm/parameters/policy can control it. The interface can be used as a boot option too. Currently we have below setting: > default BIOS default setting. > powersave Highest power saving mode, enable all available ASPM state and clock power management. > performance Highest performance, disable ASPM and clock power management. By default, the 'default' policy is used currently. In my test, power difference between powersave mode and performance mode is about 1.3w in a system with 3 PCIE links. > 'echo powersave > /sys/module/pcie_aspm/parameters/policy'? [Y/N]:
)
does this patch do the same as passing pcie_aspm=force? Or am I not grasping things properly? Just trying to make sure I am on the right page as I am learning these things. Also do you change the policy in the same manner as the other variables are modified, by echo'ing the variable you want or?
I have been adding my changes to my handler.sh, would putting this in rc.local be a better option? Not really sure I get why putting there would even be a good choice.
Thanks for helping
Last edited by vwyodajl (2012-01-27 23:19:00)
Offline
This might help: http://docs.redhat.com/docs/en-US/Red_H … /ASPM.html
Edit: tl;dr => The kernel parameter essentially disables aspm or forces it on, otherwise it simply relies on the firmware/bios correctly reporting hardware comparability. The policy then reflects the state defined within the patch.
So yes, if your hardware supports aspm but doesn't report it, you'll need to use the kernel commandline to force it. Then you may set the policy.
Hope that makes sense (and is roughly accurate).
The Red Hat Documentation actually covers a lot of these options and in fairly decent amounts of detail. I recommend the OP looking over that and compiling various descriptions for each setting and any warnings or potential problems each setting could cause.
Edit2:
Just trying to make sure I am on the right page as I am learning these things.
You should definitely research these options before randomly changing things within sysfs. This is why I think it's pretty irresponsible to just throw these into a script and expect people to use it without providing them with some detail.
Last edited by Earnestly (2012-01-28 00:22:35)
Offline
Thanks Kaustic for posting those links, my googlefu was not turning up as good of results. Will read through that stuff and see if and how it applies to my system. I agree about the researching more, just making sure I am staying on track. Definatly not just throwing these options on the system and hoping for the best, I just see a mention of using that force in grub on this site and a ton of others.
Offline
Generally it's a good idea (home use) to force ASPM as most (desktop) motherboard manufacturers don't build the bios properly to report it's capability, so to avoid stability issues Linux simply doesn't touch it*, however the can lead to an increase in power usage as the PCIe link would be running at full steam without any management. This would essentially be option 3 => performance "disables ASPM to allow PCIe links to operate with maximum performance."
* As the Red Hat documentation reads, forcing ASPM on a PCIe link which doesn't support it can lead to system freezes.
Last edited by Earnestly (2012-01-28 01:31:47)
Offline
Have you looked at this guys handler.sh?
https://bbs.archlinux.org/viewtopic.php?id=130785
Offline
after some testing, I found out that
1. i915 frame buffer compression will cause some intel graphics not rendering properly
2. set pci power to auto will cause problems on poweroff. At least on my machine.
These changes are updated in the main post.
"After you do enough distro research, you will choose Arch."
Offline
I was curious about this 'nmi-watchdog' and went googling. In support of the eventual documentation of the wiki...
My own summary:
nmi-watchdog actively checks for 'non-maskable interrupts', which at least two benefits: improved kernel hacking and scanning for hard-freezes and lockups. As the software does not necessarily recover you from such problems, it is safe to disable. nmi-watchdog does allow the kernel to dump core at the time of the interrupt, so enable this option for debugging.
http://x86vmm.blogspot.com/2005/10/linu … dware.html:
The architectural purpose for NMIs is to serve as a sort of "meta-interrupt;" they're interrupts that can interrupt interrupt handlers. This may sound ridiculous initially, but for a kernel developer, judicious use of NMIs makes it possible to port some of the luxuries of user-level development to the kernel. Consider, e.g., profiling. User-level apps typically use SIGPROF, which in turn is driven by the kernel's timer interrupt handler. But what if you're a kernel developer concerned with the performance of the timer interrupt handler itself?
NMIs provide one solution; by setting up periodic NMIs, and gathering execution samples in the NMI handler, you can peer into the performance of kernel critical sections that run with disabled interrupts. We've used this technique to good effect to study the performance of VMware's virtual machine monitor. The oprofile system-wide profiler on Linux leverages the same technique.
Another important application for NMIs is best-effort deadlock detection; an NMI "watchdog" runs perioically and looks for signs of forward progress (e.g., those counts of interrupts in /proc/interrupts rolling forward) has a decent chance of detecting most "hard" kernel hangs. 9 times out of 10, an NMI handler that detects a wedged system can't do much of use for the user. The system will crash, and often do so just as hard as if there were no NMI handler present; however, perhaps it will dump some sort of kernel core file that can be recovered after the inevitable reboot to aid kernel engineers in diagnosing the problem post-mortem. Even something as simple as pretty-printing a register dump and stack-trace to the system console provides a world of improvement in debuggability over a mute, locked-up box.
http://oslearn.blogspot.com/2011/04/use … chdog.html
http://www.mjmwired.net/kernel/Document … tchdog.txt (from the kernel docs)
A 'lockup' is the following scenario: if any CPU in the system does not
execute the period local timer interrupt for more than 5 seconds, then
the NMI handler generates an oops and kills the process. This
'controlled crash' (and the resulting kernel messages) can be used to
debug the lockup. Thus whenever the lockup happens, wait 5 seconds and
the oops will show up automatically. If the kernel produces no messages
then the system has crashed so hard (eg. hardware-wise) that either it
cannot even accept NMI interrupts, or the crash has made the kernel
unable to print messages.
Offline
Hi All,
Instead of using the script given in the first page of the thread, I did everything manually step by step.
But when i restart my machine, all settings got reverted. What is the right way to do ?
Even if i run the script, I guess after restart all the settings will be reverted. Am I missing something here ?
Regards,
Nachi
Offline
put those things you would like to use to /etc/rc.local
Offline