You are not logged in.

#26 2012-01-24 07:53:17

taylorchu
Member
Registered: 2010-08-09
Posts: 405

Re: 3x+ battery life

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

#27 2012-01-24 09:33:44

broken pipe
Member
Registered: 2010-12-10
Posts: 243

Re: 3x+ battery life

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

#28 2012-01-24 18:38:04

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: 3x+ battery life

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

#29 2012-01-25 07:33:57

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,643
Website

Re: 3x+ battery life

@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 packagesZsh and other configs

Offline

#30 2012-01-25 08:01:28

taylorchu
Member
Registered: 2010-08-09
Posts: 405

Re: 3x+ battery life

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

#31 2012-01-25 08:10:58

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,643
Website

Re: 3x+ battery life

@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 packagesZsh and other configs

Offline

#32 2012-01-25 11:57:30

vwyodajl
Member
Registered: 2012-01-21
Posts: 183

Re: 3x+ battery life

Army wrote:

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

#33 2012-01-25 13:14:23

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: 3x+ battery life

graysky wrote:

@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:

Kaustic wrote:

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

#34 2012-01-25 22:43:49

Shinryuu
Member
From: /dev/urandom
Registered: 2010-02-27
Posts: 339

Re: 3x+ battery life

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 wink

Last edited by Shinryuu (2012-01-25 23:07:46)

Offline

#35 2012-01-26 07:07:13

orschiro
Member
Registered: 2009-06-04
Posts: 2,136
Website

Re: 3x+ battery life

@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

#36 2012-01-27 00:42:10

taylorchu
Member
Registered: 2010-08-09
Posts: 405

Re: 3x+ battery life

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

#37 2012-01-27 01:26:06

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: 3x+ battery life

Kindly make sure you add explanations or links to various documentation for each parameter. (I'd personally appreciate that.)

Offline

#38 2012-01-27 14:34:25

broken pipe
Member
Registered: 2010-12-10
Posts: 243

Re: 3x+ battery life

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

#39 2012-01-27 14:43:06

el mariachi
Member
Registered: 2007-11-30
Posts: 595

Re: 3x+ battery life

@broken pipe: that sounds tasty big_smile

Offline

#40 2012-01-27 15:29:29

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: 3x+ battery life

broken pipe wrote:

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

#41 2012-01-27 19:49:28

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,643
Website

Re: 3x+ battery life

taylorchu wrote:

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 packagesZsh and other configs

Offline

#42 2012-01-27 23:16:31

vwyodajl
Member
Registered: 2012-01-21
Posts: 183

Re: 3x+ battery life

Kaustic wrote:

(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

#43 2012-01-27 23:58:47

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: 3x+ battery life

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

#44 2012-01-28 01:07:54

vwyodajl
Member
Registered: 2012-01-21
Posts: 183

Re: 3x+ battery life

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

#45 2012-01-28 01:28:44

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: 3x+ battery life

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

#46 2012-01-28 22:46:46

Haptic
Member
Registered: 2009-09-03
Posts: 149

Re: 3x+ battery life

Have you looked at this guys handler.sh?
https://bbs.archlinux.org/viewtopic.php?id=130785

Offline

#47 2012-02-11 01:49:04

taylorchu
Member
Registered: 2010-08-09
Posts: 405

Re: 3x+ battery life

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

#48 2012-02-17 13:30:50

jceasless
Member
Registered: 2009-04-20
Posts: 73

Re: 3x+ battery life

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

#49 2012-03-06 17:17:18

nachiappan
Member
From: Raleigh, NC
Registered: 2011-11-13
Posts: 25

Re: 3x+ battery life

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

#50 2012-03-06 18:31:17

broken pipe
Member
Registered: 2010-12-10
Posts: 243

Re: 3x+ battery life

put those things you would like to use to /etc/rc.local

Offline

Board footer

Powered by FluxBB