Power Management

(13 intermediate revisions by 2 users not shown)

Line 1:

~~==References==~~

Matthew Garrett's "[http://www.codon.org.uk/~mjg59/power/good_practices.html Observations on Power Management]" is a great intro.

[http://www.~~linux~~.~~com~~/~~articles~~/~~54610 linux~~.~~com article~~ on ~~hibernate and suspend~~]

==Implementations==

* APM (Advanced Power Management): All PM policy/mechanism resides within the BIOS

Line 8:

Line 6:

** No longer supported in Vista. Off by default in recent Debian kernels.

* [[ACPI]]: Current, often buggy (but also often easily repairable via BIOS flash or by hand)

** C-States, which are decomposable into P-States and T-States

* P4 Thermal Throttling: Slows down or shuts off the processor based on CPU temperature

** Adjustment is either via idle cycle insertion or lowering the clock multiplier

==CPU Frequency ~~Throttling~~==

==Batteries==

* upower can be used to get battery details, if its daemon is running:

<pre>upower -i /org/freedesktop/UPower/devices/battery_BAT1

native-path: BAT1

vendor: SMP

model: 01AV452

serial: 5642

power supply: yes

updated: Sun 15 Jul 2018 12:33:08 PM EDT (104 seconds ago)

has history: yes

has statistics: yes

battery

present: yes

rechargeable: yes

state: discharging

warning-level: none

energy: 15.94 Wh

energy-empty: 0 Wh

energy-full: 24.54 Wh

energy-full-design: 24 Wh

energy-rate: 7.994 W

voltage: 11.405 V

time to empty: 2.0 hours

percentage: 66%

capacity: 100%

technology: lithium-polymer

icon-name: 'battery-full-symbolic'

History (charge):

1531672388 66.000 discharging

History (rate):

1531672388 7.994 discharging</pre>

==CPU Frequency==

* On Linux, <tt>cpufreq-info</tt> provides lots of good information:

<pre>[recombinator](0) $ cpufreq-info

Line 37:

Line 70:

cpufreq stats: 2.39 GHz:4.32%, 1.60 GHz:95.68% (19387)

[recombinator](0) $ </pre>

* You can get C-state latency information from <tt>/proc/acpi/processor/*/power</tt>:

<pre>[wopr](0) $ cat /proc/acpi/processor/CP10/power

active state: C0

max_cstate: C8

maximum allowed latency: 2000000000 usec

states:

C1: type[C1] promotion[--] demotion[--] latency[032] usage[02035391] duration[00000000000000000000]

C2: type[C2] promotion[--] demotion[--] latency[064] usage[01050475] duration[00000000000624232458]

C3: type[C2] promotion[--] demotion[--] latency[096] usage[150501625] duration[00000020175094863449]

[wopr](0) $ </pre>

* On [[FreeBSD]], sysctls from the dev.cpu and debug.cpufreq MIB hierarchies are your window into frequency control. See [http://www.freebsd.org/cgi/man.cgi?query=cpufreq&apropos=0&sektion=0&format=html cpufreq(4)].

==Disks/Filesystems==

* noatime -- critical for all kinds of things! ''~~FIXME~~: ~~find~~ and ~~add great Ingo Molnar quote~~''

* noatime -- critical for all kinds of things! don't believe me; trust [http://article.gmane.org/gmane.linux.kernel/565148 ingo molnár]:

<pre>i cannot over-emphasise how much of a deal it is in practice. Atime

updates are by far the biggest IO performance deficiency that Linux has

today. Getting rid of atime updates would give us more everyday Linux

performance than all the pagecache speedups of the past 10 years,

_combined_.

it's also perhaps the most stupid Unix design idea of all times. Unix is

really nice and well done, but think about this a bit:

' For every file that is read from the disk, lets do a ... write to

the disk! And, for every file that is already cached and which we

read from the cache ... do a write to the disk! '

tell that concept to any rookie programmer who knows nothing about

kernels and the answer will be: 'huh, what? That's gross!'. And Linux

does this unconditionally for everything, and no, it's not only done on

some high-security servers that need all sorts of auditing enabled that

logs every file read - no, it's done by 99% of the Linux desktops and

servers. For the sake of some lazy mailers that could now be using

inotify, and for the sake of ... nothing much, really - forensics

software perhaps.</pre>

* [[SATA]] link state management? what is this? seen in <tt>powertop</tt> output

* turning up the writeback time / disk head parking / other debatable techniques

==Workload Distribution==

* The <tt>/sys/devices/system/cpu/sched_smt_power_savings</tt> tunable causes tasks (under light load) to be preferentially distributed across processing elements (ie including [[SMP on x86|SMT]] units) and cores of physical packages (as opposed to packages themselves).

* The <tt>/sys/devices/system/cpu/sched_mc_power_savings</tt> tunable does the same, but doesn't apply to SMT.

* Task migration has overhead and associated [[architecture]] warmup (ie, caches, branch prediction and hardware prefetching). How is this affected? '''FIXME'''

==Networking==

===Wired===

* Disable Wake-on-LAN if it's not being used: <tt>ethtool -s DEVICE wol d</tt>

===Wireless===

* PS-Poll (PowerSave Poll) turns the radio off longer in exchange for higher latencies (only when it's disabled, though)

** Requires support from access point

* Auto-association / aggressive scanning, especially when wireless is not being used

* MAC80211_DEFAULT_PS, introduced in the 2.6.32 development cycle, sets wireless powersaving by default

** Use latency requirement registration (Documentation/power/pm_qos_interface.txt) for applications which need it

==See Also==

* [http://www.vanshardware.com/articles/2001/july/010723_P4_Throttling/010723_P4_Throttling.htm P4 Thermal Throttling] at Van's Hardware Journal

* [http://www.hardwaresecrets.com/article/104 P4 Thermal Throttling] at Hardware Secrets

* [http://www.linux.com/articles/54610 linux.com article on hibernate and suspend]

* lesswatts.org article on [http://www.lesswatts.org/tips/cpu.php power-aware scheduling] for multicores

* lesswatts.org article on [http://www.lesswatts.org/tips/wireless.php wireless] power-saving

Power Management: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
-==References==
+Matthew Garrett's "[http://www.codon.org.uk/~mjg59/power/good_practices.html Observations on Power Management]" is a great intro.
-[http://www.linux.com/articles/54610 linux.com article on hibernate and suspend]
 ==Implementations==
 * APM (Advanced Power Management): All PM policy/mechanism resides within the BIOS
@@ Line 8: / Line 6: @@
 ** No longer supported in Vista. Off by default in recent Debian kernels.
 * [[ACPI]]: Current, often buggy (but also often easily repairable via BIOS flash or by hand)
+** C-States, which are decomposable into P-States and T-States
+* P4 Thermal Throttling: Slows down or shuts off the processor based on CPU temperature
+** Adjustment is either via idle cycle insertion or lowering the clock multiplier
-==CPU Frequency Throttling==
+==Batteries==
+* upower can be used to get battery details, if its daemon is running:
+<pre>upower -i /org/freedesktop/UPower/devices/battery_BAT1
+  native-path:          BAT1
+  vendor:               SMP
+  model:                01AV452
+  serial:               5642
+  power supply:         yes
+  updated:              Sun 15 Jul 2018 12:33:08 PM EDT (104 seconds ago)
+  has history:          yes
+  has statistics:       yes
+  battery
+    present:             yes
+    rechargeable:        yes
+    state:               discharging
+    warning-level:       none
+    energy:              15.94 Wh
+    energy-empty:        0 Wh
+    energy-full:         24.54 Wh
+    energy-full-design:  24 Wh
+    energy-rate:         7.994 W
+    voltage:             11.405 V
+    time to empty:       2.0 hours
+    percentage:          66%
+    capacity:            100%
+    technology:          lithium-polymer
+    icon-name:          'battery-full-symbolic'
+  History (charge):
+    1531672388	66.000	discharging
+  History (rate):
+    1531672388	7.994	discharging</pre>
+==CPU Frequency==
 * On Linux, <tt>cpufreq-info</tt> provides lots of good information:
 <pre>[recombinator](0) $ cpufreq-info
@@ Line 37: / Line 70: @@
    cpufreq stats: 2.39 GHz:4.32%, 1.60 GHz:95.68%  (19387)
 [recombinator](0) $ </pre>
+* You can get C-state latency information from <tt>/proc/acpi/processor/*/power</tt>:
+<pre>[wopr](0) $ cat /proc/acpi/processor/CP10/power
+active state:            C0
+max_cstate:              C8
+maximum allowed latency: 2000000000 usec
+states:
+    C1:                  type[C1] promotion[--] demotion[--] latency[032] usage[02035391] duration[00000000000000000000]
+    C2:                  type[C2] promotion[--] demotion[--] latency[064] usage[01050475] duration[00000000000624232458]
+    C3:                  type[C2] promotion[--] demotion[--] latency[096] usage[150501625] duration[00000020175094863449]
+[wopr](0) $ </pre>
 * On [[FreeBSD]], sysctls from the dev.cpu and debug.cpufreq MIB hierarchies are your window into frequency control. See [http://www.freebsd.org/cgi/man.cgi?query=cpufreq&apropos=0&sektion=0&format=html cpufreq(4)].
 ==Disks/Filesystems==
-* noatime -- critical for all kinds of things! ''FIXME: find and add great Ingo Molnar quote''
+* noatime -- critical for all kinds of things! don't believe me; trust [http://article.gmane.org/gmane.linux.kernel/565148 ingo molnár]:
+<pre>i cannot over-emphasise how much of a deal it is in practice. Atime
+updates are by far the biggest IO performance deficiency that Linux has
+today. Getting rid of atime updates would give us more everyday Linux
+performance than all the pagecache speedups of the past 10 years,
+_combined_.
+it's also perhaps the most stupid Unix design idea of all times. Unix is
+really nice and well done, but think about this a bit:
+   ' For every file that is read from the disk, lets do a ... write to
+     the disk! And, for every file that is already cached and which we
+     read from the cache ... do a write to the disk! '
+tell that concept to any rookie programmer who knows nothing about
+kernels and the answer will be: 'huh, what? That's gross!'. And Linux
+does this unconditionally for everything, and no, it's not only done on
+some high-security servers that need all sorts of auditing enabled that
+logs every file read - no, it's done by 99% of the Linux desktops and
+servers. For the sake of some lazy mailers that could now be using
+inotify, and for the sake of ... nothing much, really - forensics
+software perhaps.</pre>
 * [[SATA]] link state management? what is this? seen in <tt>powertop</tt> output
 * turning up the writeback time / disk head parking / other debatable techniques
+==Workload Distribution==
+* The <tt>/sys/devices/system/cpu/sched_smt_power_savings</tt> tunable causes tasks (under light load) to be preferentially distributed across processing elements (ie including [[SMP on x86|SMT]] units) and cores of physical packages (as opposed to packages themselves).
+* The <tt>/sys/devices/system/cpu/sched_mc_power_savings</tt> tunable does the same, but doesn't apply to SMT.
+* Task migration has overhead and associated [[architecture]] warmup (ie, caches, branch prediction and hardware prefetching). How is this affected? '''FIXME'''
+==Networking==
+===Wired===
+* Disable Wake-on-LAN if it's not being used: <tt>ethtool -s DEVICE wol d</tt>
+===Wireless===
+* PS-Poll (PowerSave Poll) turns the radio off longer in exchange for higher latencies (only when it's disabled, though)
+** Requires support from access point
+* Auto-association / aggressive scanning, especially when wireless is not being used
+* MAC80211_DEFAULT_PS, introduced in the 2.6.32 development cycle, sets wireless powersaving by default
+** Use latency requirement registration (Documentation/power/pm_qos_interface.txt) for applications which need it
+==See Also==
+* [http://www.vanshardware.com/articles/2001/july/010723_P4_Throttling/010723_P4_Throttling.htm P4 Thermal Throttling] at Van's Hardware Journal
+* [http://www.hardwaresecrets.com/article/104 P4 Thermal Throttling] at Hardware Secrets
+* [http://www.linux.com/articles/54610 linux.com article on hibernate and suspend]
+* lesswatts.org article on [http://www.lesswatts.org/tips/cpu.php power-aware scheduling] for multicores
+* lesswatts.org article on [http://www.lesswatts.org/tips/wireless.php wireless] power-saving