The text o f and illustrations in this document are licensed by Red Hatunder a Creative Commons Attribution–Share Alike 3.0 Unportedlicense ("CC-BY-SA"). An explanation o f CC-BY-SA is available athttp://creativecommons.org/licenses/by-sa/3.0/. The original authors o fthis document, and Red Hat, designate the Fedora Pro ject as the"Attribution Party" fo r purposes o f CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation o f it, you mustprovide the URL for the original version.
Red Hat, as the licensor o f this document, waives the right to enforce,and agrees not to assert, Section 4d o f CC-BY-SA to the fullest extentpermitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss,
MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks o f RedHat, Inc., registered in the United States and o ther countries.
For guidelines on the permitted uses o f the Fedora trademarks, refer tohttps://fedorapro ject.org/wiki/Legal:Trademark_guidelines.
Linux® is the registered trademark o f Linus Torvalds in the UnitedStates and o ther countries.
Java® is a registered trademark o f Oracle and/or its affiliates.
XFS® is a trademark o f Silicon Graphics International Corp. or itssubsidiaries in the United States and/or o ther countries.
MySQL® is a registered trademark o f MySQL AB in the United States,the European Union and o ther countries.
All o ther trademarks are the property o f their respective owners.
AbstractThe Power Management Guide documents how to manage powerconsumption on Fedora 20 systems effectively. It discusses differenttechniques that lower power consumption for both server and laptop,and explains how each technique affects the overall performance o fyour system.
Preface
1. Document Conventions
1.1. Typographic Conventions1.2. Pull-quote Conventions1.3. Notes and Warnings
2. We Need Feedback!
1. Overview
1.1. Importance o f Power Management1.2. Power Management Basics
2. Power Management Auditing and Analysis
2.1. Audit and Analysis Overview2.2. PowerTOP2.3. Diskdevstat and netdevstat2.4. Battery Life Too l Kit2.5. Tuned
2.5.1. Plugins2.5.2. Provided Profiles2.5.3. Installation and Usage2.5.4. Custom Profiles2.5.5. Powertop2tuned
2.6. UPower2.7. GNOME Power Manager2.8. acpid2.9. Other Too ls fo r Auditing
3. Core Infrastructure and Mechanics
3.1. CPU Idle States3.2. Using CPUfreq Governors
3.2.1. CPUfreq Governor Types3.2.2. CPUfreq Setup3.2.3. Tuning CPUfreq Po licy and Speed
3.4. CPU Power Saving Po licies3.5. Suspend and Resume3.6. Tickless Kernel3.7. Active-State Power Management3.8. Aggressive Link Power Management3.9. Relatime Drive Access Optimization3.10. Power Capping3.11. Enhanced Graphics Power Management3.12. RFKill3.13. Optimizations in User Space
4. Use Cases
4.1. Example — Server4.2. Example — Laptop
A. Tips for Developers
A.1. Using ThreadsA.2. Wake-upsA.3. Fsync
B. Revision History
4 Power Management Guide
Preface1. Document ConventionsThis manual uses several conventions to highlight certain words andphrases and draw attention to specific pieces o f information.
In PDF and paper editions, this manual uses typefaces drawn from theLiberation Fonts set. The Liberation Fonts set is also used in HTMLeditions if the set is installed on your system. If no t, alternative butequivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5and later includes the Liberation Fonts set by default.
1.1. Typographic ConventionsFour typographic conventions are used to call attention to specificwords and phrases. These conventions, and the circumstances theyapply to , are as fo llows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file namesand paths. Also used to highlight keycaps and key combinations. Forexample:
To see the contents o f the file my_next_bestselling_novel in your current workingdirectory, enter the cat my_next_bestselling_novelcommand at the shell prompt and press Enter to executethe command.
The above includes a file name, a shell command and a keycap, allpresented in mono-spaced bo ld and all distinguishable thanks tocontext.
Key combinations can be distinguished from keycaps by the hyphenconnecting each part o f a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to the first virtual terminal.Press Ctrl+Alt+F1 to return to your X-Windowssession.
The first paragraph highlights the particular keycap to press. The secondhighlights two key combinations (each a set o f three keycaps with eachset pressed simultaneously).
If source code is discussed, class names, methods, functions, variablenames and returned values mentioned within a paragraph will bepresented as above, in mono-spaced bold. For example:
File-related classes include filesystem fo r file systems, file fo r files, and dir fo r directories. Each class has itsown associated set o f permissions.
Pro po rt io nal Bo ld
This denotes words or phrases encountered on a system, includingapplication names; dialog box text; labeled buttons; check-box andradio button labels; menu titles and sub-menu titles. For example:
Choose Syst em → Preferences → Mo use from themain menu bar to launch Mo use Preferences. In theButtons tab, click the Left-handed mouse check boxand click Close to switch the primary mouse button fromthe left to the right (making the mouse suitable for use inthe left hand).
To insert a special character into a gedit file, choose
Applicat io ns → Accesso ries → Charact er Map fromthe main menu bar. Next, choose Search → Find… fromthe Charact er Map menu bar, type the name of thecharacter in the Search field and click Next. The characteryou sought will be highlighted in the Character Table.Double-click this highlighted character to place it in theText to copy field and then click the Copy button. Nowswitch back to your document and choose Edit → Past efrom the gedit menu bar.
The above text includes application names; system-wide menu namesand items; application-specific menu names; and buttons and text foundwithin a GUI interface, all presented in proportional bo ld and alldistinguishable by context.
Mono-spaced Bold Italic o r Proportional Bold Italic
Whether mono-spaced bo ld or proportional bo ld, the addition o f italicsindicates replaceable or variable text. Italics denotes text you do notinput literally or displayed text that changes depending on circumstance.For example:
To connect to a remote machine using ssh, type ssh [email protected] at a shell prompt. If the remotemachine is example.com and your username on thatmachine is john, type ssh [email protected].
The mount -o remount file-system commandremounts the named file system. For example, toremount the /home file system, the command is mount -o remount /home.
To see the version o f a currently installed package, usethe rpm -q package command. It will return a result asfo llows: package-version-release.
Note the words in bo ld italics above — username, domain.name, file-system, package, version and release. Each word is a placeho lder,either fo r text you enter when issuing a command or fo r text displayedby the system.
Aside from standard usage for presenting the title o f a work, italicsdenotes the first use o f a new and important term. For example:
Publican is a DocBook publishing system.
1.2. Pull-quote ConventionsTerminal output and source code listings are set o ff visually from thesurrounding text.
Output sent to a terminal is set in mono-spaced roman and presentedthus:
1.3. Notes and WarningsFinally, we use three visual styles to draw attention to information thatmight o therwise be overlooked.
Note
Notes are tips, shortcuts or alternative approaches to the task athand. Ignoring a note should have no negative consequences,but you might miss out on a trick that makes your life easier.
Important
Important boxes detail things that are easily missed:configuration changes that only apply to the current session, orservices that need restarting before an update will apply. Ignoringa box labeled 'Important' will no t cause data loss but may causeirritation and frustration.
Warning
Warnings should not be ignored. Ignoring warnings will mostlikely cause data loss.
2. We Need Feedback!If you find a typographical error in this manual, o r if you have thought o fa way to make this manual better, we would love to hear from you!Please submit a report in Bugzilla: http://bugzilla.redhat.com/bugzilla/against the product Fedo ra Do cument at io n.
When submitting a bug report, be sure to mention the manual'sidentifier: power-management-guide
If you have a suggestion for improving the documentation, try to be asspecific as possible when describing it. If you have found an error,please include the section number and some of the surrounding text sowe can find it easily.
Chapter 1. Overview1.1. Importance o f Power Management
1.2. Power Management Basics
Limiting the power used by computer systems is one o f the mostimportant aspects o f green IT (environmentally friendly computing), a seto f considerations that also encompasses the use o f recyclablematerials, the environmental impact o f hardware production, andenvironmental awareness in the design and deployment o f systems. Inthis document, we provide guidance and information regarding powermanagement o f your systems running Fedora 20.
1.1. Importance of Power ManagementAt the core o f power management is an understanding o f how toeffectively optimize energy consumption o f each system component.This entails studying the different tasks that your system performs, andconfiguring each component to ensure that its performance is just rightfor the job.
The main motivator fo r power management is:
reducing overall power consumption to save cost
The proper use o f power management results in:
heat reduction for servers and computing centers
reduced secondary costs, including coo ling, space, cables,generators, and uninterruptible power supplies (UPS)
extended battery life fo r laptops
lower carbon dioxide output
meeting government regulations or legal requirements regardingGreen IT, fo r example Energy Star
meeting company guidelines for new systems
As a rule, lowering the power consumption o f a specific component (oro f the system as a whole) will lead to lower heat and naturally,performance. As such, you should thoroughly study and test thedecrease in performance afforded by any configurations you make,especially fo r mission-critical systems.
By studying the different tasks that your system performs, andconfiguring each component to ensure that its performance is justsufficient fo r the job, you can save energy, generate less heat, andoptimize battery life fo r laptops. Many o f the principles for analysis andtuning o f a system in regard to power consumption are similar to thosefor performance tuning. To some degree, power management andperformance tuning are opposite approaches to system configuration,because systems are usually optimized either towards performance orpower. This manual describes the too ls that the Fedora Pro ject providesand the techniques we have developed to help you in this process.
Fedora 20 already comes with a lo t o f new power management featuresthat are enabled by default. They were all selectively chosen to notimpact the performance o f a typical server or desktop use case.However, fo r very specific use cases where maximum throughput,lowest latency, or highest CPU performance is abso lutely required, areview of those defaults might be necessary.
To decide whether you should optimize your machines using thetechniques described in this document, ask yourself a few questions:
Q: Must I optimize?Q: How much do I need to optimize?Q: Will optimization reduce system performance to an unacceptablelevel?Q: Will the time and resources spent to optimize the system outweigh
8 Chapter 1. Overview
Q:
A:
Q:
A:
Q:
A:
Q:
A:
the gains achieved?
Must I o pt imize?
The importance o f power optimization depends on whether yourcompany has guidelines that need to be fo llowed or if there areany regulations that you have to fulfill.
Ho w much do I need t o o pt imize?
Several o f the techniques we present do not require you to gothrough the whole process o f auditing and analyzing yourmachine in detail but instead o ffer a set o f general optimizationsthat typically improve power usage. Those will o f course typicallynot be as good as a manually audited and optimized system, butprovide a good compromise.
Will o pt imizat io n reduce syst em perfo rmance t o anunaccept able level?
Most o f the techniques described in this document impact theperformance o f your system noticeably. If you choose toimplement power management beyond the defaults already inplace in Fedora 20, you should monitor the performance o f thesystem after power optimization and decide if the performanceloss is acceptable.
Will t he t ime and reso urces spent t o o pt imize t he syst emo ut weigh t he gains achieved?
Optimizing a single system manually fo llowing the whole processis typically not worth it as the time and cost spent do ing so is farhigher than the typical benefit you would get over the lifetime o f asingle machine. On the o ther hand if you for example ro ll out10000 desktop systems to your o ffices all using the sameconfiguration and setup then creating one optimized setup andapplying that to all 10000 machines is most likely a good idea.
The fo llowing sections will explain how optimal hardware performancebenefits your system in terms o f energy consumption.
1.2. Power Management BasicsEffective power management is built on the fo llowing principles:
An idle CPU sho uld o nly wake up when needed
The kernel used in releases o f Fedora prio r to Fedora 18 used aperiodic timer fo r each CPU. This timer prevents the CPU from trulygo ing idle, as it requires the CPU to process each timer event (whichwould happen every few milliseconds, depending on the setting),regardless o f whether any process was running or not. A large part o feffective power management invo lves reducing the frequency at whichCPU wakeups are made.
Because o f this, the Linux kernel in Fedora 20 eliminates the periodictimer: as a result, the idle state o f a CPU is now tickless. This preventsthe CPU from consuming unnecessary power when it is idle. However,benefits from this feature can be o ffset if your system has applicationsthat create unnecessary timer events. Po lling events (such as checks forvo lume changes, mouse movement, and the like) are examples o f suchevents.
Fedora 20 includes too ls with which you can identify and auditapplications on the basis o f their CPU usage. Refer to Chapter 2, PowerManagement Auditing and Analysis fo r details.
Unused hardware and devices sho uld be disabled co mplet e ly
This is especially true for devices that have moving parts (fo r example,hard disks). In addition to this, some applications may leave an unused
Fedora 20 Power Management Guide 9
but enabled device "open"; when this occurs, the kernel assumes thatthe device is in use, which can prevent the device from go ing into apower saving state.
Lo w act ivit y sho uld t ranslat e t o lo w wat t age
In many cases, however, this depends on modern hardware and correctBIOS configuration. Older system components o ften do not havesupport fo r some of the new features that we now can support inFedora 20. Make sure that you are using the latest o fficial firmware foryour systems and that in the power management or deviceconfiguration sections o f the BIOS the power management features areenabled. Some features to look for include:
SpeedStep
PowerNow!
Cool'n'Quiet
ACPI (C state)
Smart
If your hardware has support fo r these features and they are enabled inthe BIOS, Fedora 20 will use them by default.
Different fo rms o f CPU st at es and t heir effect s
Modern CPUs together with Advanced Configuration and Power Interface(ACPI) provide different power states. The three different states are:
Sleep (C-states)
Frequency (P-states)
Heat output (T-states or "thermal states")
A CPU running on the lowest sleep state possible (indicated by thehighest C-state number) consumes the least amount o f watts, but it alsotakes considerably more time to wake it up from that state when needed.In very rare cases this can lead to the CPU having to wake upimmediately every time it just went to sleep. This situation results in aneffectively permanently busy CPU and loses some of the potentialpower saving if another state had been used.
A t urned o ff machine uses t he least amo unt o f po wer
As obvious as this might sound, one o f the best ways to actually savepower is to turn o ff systems. For example, your company can develop acorporate culture focused on "green IT" awareness with a guideline toturn o f machines during lunch break or when go ing home. You alsomight conso lidate several physical servers into one bigger server andvirtualize them using the virtualization techno logy we ship withFedora 20.
10 Chapter 1. Overview
Chapter 2. PowerManagement Auditingand Analysis2.1. Audit and Analysis Overview
2.2. PowerTOP
2.3. Diskdevstat and netdevstat
2.4. Battery Life Too l Kit
2.5. Tuned
2.5.1. Plugins2.5.2. Provided Profiles2.5.3. Installation and Usage2.5.4. Custom Profiles2.5.5. Powertop2tuned
2.6. UPower
2.7. GNOME Power Manager
2.8. acpid
2.9. Other Too ls fo r Auditing
2.1. Audit and Analysis OverviewThe detailed manual audit, analysis, and tuning o f a single system isusually the exception because the time and cost spent to do so typicallyoutweighs the benefits gained from these last pieces o f system tuning.However, performing these tasks once for a large number o f nearlyidentical systems where you can reuse the same settings for allsystems can be very useful. For example, consider the deployment o fthousands o f desktop systems, or a HPC cluster where the machinesare nearly identical. Another reason to do auditing and analysis is toprovide a basis fo r comparison against which you can identifyregressions or changes in system behavior in the future. The results o fthis analysis can be very helpful in cases where hardware, BIOS, orsoftware updates happen regularly and you want to avo id any surpriseswith regard to power consumption. Generally, a thorough audit andanalysis gives you a much better idea o f what is really happening on aparticular system.
Auditing and analyzing a system with regard to power consumption isrelatively hard, even with the most modern systems available. Mostsystems do not provide the necessary means to measure power usevia software. Exceptions exist though: the ILO management conso le o fHewlett Packard server systems has a power management module thatyou can access through the web. IBM provides a similar so lution in theirBladeCenter power management module. On some Dell systems, theIT Assistant o ffers power monitoring capabilities as well. Other vendorsare likely to o ffer similar capabilities for their server platforms, but as canbe seen there is no single so lution available that is supported by allvendors. If your system has no inbuilt mechanism to measure powerconsumption, a few other cho ices exist. You could install a specialpower supply fo r your system that o ffers power consumptioninformation through USB. The Gigabyte Odin GT 550 W PC powersupply is one such example, and software to read out those valuesunder Linux is available externally fromhttp://mgmt.sth.sze.hu/~andras/dev/gopsu/. As a last resort, someexternal watt meters like the Watts up? PRO have a USB connector.
Direct measurements o f power consumption is o ften only necessary to
maximize savings as far as possible. Fortunately, o ther means areavailable to measure if changes are in effect or how the system isbehaving. This chapter describes the necessary too ls.
2.2. PowerTOPThe tickless kernel in Fedora allows the CPU to enter the idle state morefrequently, reducing power consumption and improving powermanagement. The new Po werT OP too l identifies specific componentsof kernel and user-space applications that frequently wake up the CPU.Po werT OP was used in development to perform the audits describedin Section 3.13, “Optimizations in User Space” that led to manyapplications being tuned in this release, reducing unnecessary CPUwake up by a factor o f ten.
Fedora 20 comes with version 2.x o f Po werT OP . This version is acomplete rewrite o f the 1.x code base. It features a clearer tab-baseduser interface and extensively uses the kernel "perf" infrastructure togive more accurate data. The power behavior o f system devices istracked and prominently displayed, so problems can be pinpo intedquickly. More experimentally, the 2.x codebase includes a powerestimation engine that can indicate how much power individual devicesand processes are consuming. Refer to Figure 2.1, “PowerTOP inOperation”.
Install Po werT OP with the command:
yum install powertop
Po werT OP can provide an estimate o f the to tal power usage o f thesystem and show individual power usage for each process, device,kernel work, timer, and interrupt handler. Laptops should run on batterypower during this task. To calibrate the power estimation engine, run thefo llowing command as root:
powertop --calibrate
Calibration takes time. The process performs various tests, and willcycle through brightness levels and switch devices on and o ff. Do nottouch the machine during the calibration. When the calibration processfinishes, Po werT OP starts as normal. Let it run for approximately anhour to co llect data. When enough data is co llected, power estimationfigures will begin appearing in the first co lumn.
You can run Po werT OP with the fo llowing command as root:
powertop
If you are executing the command on a laptop, it should still be runningon battery power so that all available data will be presented.
While it runs, Po werT OP gathers statistics from the system. In theOverview tab, you can view a list o f the components that are eithersending wake-ups to the CPU most frequently or are consuming themost power (refer to Figure 2.1, “PowerTOP in Operation”). Theadjacent co lumns display power estimation, how the resource is beingused, wakeups per second, the classification o f the component (suchas process, device, or timer), and a description o f the component.Wakeups per second indicates how efficiently the services or thedevices and drivers o f the kernel are performing. Less wakeups meansless power is consumed. Components are ordered by how muchfurther their power usage can be optimized.
Tuning driver components typically requires kernel changes, which isbeyond the scope o f this document. However, userland processes thatsend wakeups are more easily managed. First, determine whether thisservice or application needs to run at all on this system. If no t, simplydeactivate it. To turn o ff an o ld SYSV service permanently, run:
systemctl disable servicename.service
For more details about the the process, run:
12 Chapter 2. Power Management Auditing and Analysis
If the trace looks like it is repeating itself, then you probably have found abusy loop. Fixing such bugs typically requires a code change in thatcomponent, which again goes beyond the scope o f this document.Please report such issues into the Bugzilla.
As seen in Figure 2.1, “PowerTOP in Operation”, to tal powerconsumption and the remaining battery life are displayed, if applicable.Below these is a short summary, featuring to tal wakeups per second,GPU operations per second, and virtual filesystem operations persecond. In the rest o f the screen there is a list o f processes, interrupts,devices and o ther resources sorted according their utilization. Ifproperly calibrated, a power consumption estimation for every listeditem in the first co lumn is shown as well.
Use the Tab and Shift+Tab keys to cycle through tabs. In theIdle stats tab, use o f C-states is shown for all processors and cores.In the Frequency stats tab, use o f P-states including the Turbo mode(if applicable) is shown for all processors and cores. The longer theCPU stays in the higher C- or P-states, the better (C4 being higher than C3). This is a good indication o f how well CPU usage has beenoptimized. Residency should ideally be 90% or more in the highest C-or P-state while the system is idle.
The Device Stats tab provides similar information to Overview butonly fo r devices.
The Tunables tab contains suggestions for optimizing the system forlower power consumption. Use the up and down keys to move throughsuggestions and the enter key to toggle the suggestion on and o ff.
Important
These tunings are not persistent across reboots. To make thempersistent you can use the po wert o p2t uned too l (refer toSection 2.5.5, “Powertop2tuned”).
Figure 2.1. Po werT OP in Operat io n
You can also generate HTML reports by running Po werT OP with the --html option. Replace the htmlfile.html parameter with the desiredname for the output file:
powertop --html=htmlfile.html
By default Po werT OP takes measurements in 20 seconds intervals,you can change it with the --time option:
powertop --html=htmlfile.html --time=seconds
The Less Watts website publishes a list o f applications that Po werT OPhas identified as keeping CPUs active. For more details, refer to
2.3. Diskdevstat and netdevstatDiskdevst at and net devst at are Syst emT ap too ls that co llectdetailed information about the disk activity and network activity o f allapplications running on a system. These too ls were inspired byPo werT OP , which shows the number o f CPU wakeups by everyapplication per second (refer to Section 2.2, “PowerTOP”). The statisticsthat these too ls co llect allow you to identify applications that wastepower with many small I/O operations rather than fewer, largeroperations. Other monitoring too ls that measure only transfer speedsdo not help to identify this type o f usage.
First, install kernel-debuginfo with the fo llowing command:
debuginfo-install kernel
Then install the too ls with Syst emT ap:
yum install systemtap tuned-utils-systemtap
Run the too ls with the command:
diskdevstat
or the command:
netdevstat
Both commands can take up to three parameters, as fo llows:
These three applications have a WRITE_CNT greater than 0, whichmeans that they performed some form of write during the measurement.Of those, plasma was the worst o ffender by a large degree: it performedthe most write operations, and o f course the average time betweenwrites was the lowest. Plasma would therefore be the best candidate toinvestigate if you were concerned about power-inefficient applications.
Use the st race and lt race commands to examine applications moreclosely by tracing all system calls o f the given process ID. In the presentexample, you could run:
strace -p 2789
In this example, the output o f the strace contained a repeating patternevery 45 seconds that opened the KDE icon cache file o f the user fo rwriting fo llowed by an immediate close o f the file again. This led to a
16 Chapter 2. Power Management Auditing and Analysis
necessary physical write to the hard disk as the file metadata(specifically, the modification time) had changed. The final fix was toprevent those unnecessary calls when no updates to the icons hadoccurred.
2.4. Battery Life Tool KitThe Bat t ery Life T o o l Kit (BLTK), is a test suite that simulates andanalyzes battery life and performance. BLTK achieves this by performingsets o f tasks that simulate specific user groups and reporting on theresults. Although developed specifically to test notebook performance,BLTK can also report on the performance o f desktop computers whenstarted with the -a.
BLTK allows you to generate very reproducible workloads that arecomparable to real use o f a machine. For example, the officeworkload writes a text, corrects things in it, and does the same for aspreadsheet. Running BLTK combined with Po werT OP o r any o f theother auditing or analysis too l allows you to test if the optimizations youperformed have an effect when the machine is actively in use instead o fonly idling. Because you can run the exact same workload multipletimes for different settings, you can compare results fo r differentsettings.
Install BLTK with the command:
yum install bltk
Run BLTK with the command:
bltk workload options
For example, to run the idle workload for 120 seconds:
bltk -I -T 120
The workloads available by default are:
-I, --idlesystem is idle, to use as a baseline for comparison with o therworkloads
-R, --readersimulates reading documents (by default, with Firefo x)
-P, --playersimulates watching multimedia files from a CD or DVD drive (bydefault, with mplayer)
-O, --officesimulates editing documents with the OpenOffice.o rg suite
Other options allow you to specify:
-a, --ac-ignoreignore whether AC power is available (necessary for desktop use)
-T number_of_seconds, --time number_of_secondsthe time (in seconds) over which to run the test; use this option withthe idle workload
-F filename, --file filenamespecifies a file to be used by a particular workload, fo r example, afile fo r the player workload to play instead o f accessing the CD orDVD drive
-W application, --prog application
Fedora 20 Power Management Guide 17
specifies an application to be used by a particular workload, fo rexample, a browser o ther than Firefo x fo r the reader workload
BLTK supports a large number o f more specialized options. For details,refer to the bltk man page.
BLTK saves the results that it generates in a directory specified in the /etc/bltk.conf configuration file — by default, ~/.bltk/workload.results.number/. For example, the ~/.bltk/reader.results.002/ directory ho lds the results o f the thirdtest with the reader workload (the first test is not numbered). Theresults are spread across several text files. To condense these resultsinto a format that is easy to read, run:
bltk_report path_to_results_directory
The results now appear in a text file named Report in the resultsdirectory. To view the results in a terminal emulator instead, use the -ooption:
bltk_report -o path_to_results_directory
2.5. TunedT uned is a daemon that uses udev to monitor connected devices andstatically and dynamically tunes system settings according to a selectedprofile. It is distributed with a number o f predefined pro files for commonuse cases like high throughput, low latency, or powersave, and allowsyou to further alter the rules defined for each pro file and customize howto tune a particular device. To revert all changes made to the systemsettings by a certain pro file, you can either switch to another pro file ordeactivate the t uned daemon.
The static tuning mainly consists o f the application o f predefined sysctland sysfs settings and one-shot activation o f several configurationtoo ls like et ht o o l. T uned also monitors the use o f systemcomponents and tunes system settings dynamically based on thatmonitoring information. Dynamic tuning accounts for the way thatvarious system components are used differently throughout the uptimefor any given system. For example, the hard drive is used heavily duringstartup and login, but is barely used later when the user might mainlywork with applications such as web browsers or email clients. Similarly,the CPU and network devices are used differently at different times.T uned monitors the activity o f these components and reacts to thechanges in their use.
As a practical example, consider a typical o ffice workstation. Most o f thetime, the Ethernet network interface will be very inactive. Only a fewemails will go in and out every once in a while or some web pagesmight be loaded. For those kinds o f loads, the network interface doesnot have to run at full speed all the time, as it does by default. T unedhas a monitoring and tuning plugin for network devices that can detectthis low activity and then automatically lower the speed o f that interface,typically resulting in a lower power usage. If the activity on the interfaceincreases for a longer period o f time, fo r example because a DVDimage is being downloaded or an email with a large attachment isopened, t uned detects this and sets the interface speed to maximum tooffer the best performance while the activity level is so high. Thisprinciple is used for o ther plugins for CPU and hard disks as well.
2.5.1. PluginsIn general, t uned uses two types o f plugins: monitoring plugins andtuning plugins. Monitoring plugins are used to get information from arunning system. Currently, the fo llowing monitoring plugins areimplemented:
disk
Gets disk load (number o f IO operations) per device andmeasurement interval.
18 Chapter 2. Power Management Auditing and Analysis
net
Gets network load (number o f transferred packets) per network cardand measurement interval.
load
Gets CPU load per CPU and measurement interval.
The output o f the monitoring plugins can be used by tuning plugins fordynamic tuning. Currently implemented dynamic tuning algorithms try tobalance the performance and powersave and are therefore disabled inthe performance pro files (dynamic tuning for individual plugins can beenabled or disabled in the t uned pro files). Monitoring plugins areautomatically instantiated whenever their metrics are needed by any o fthe enabled tuning plugins. If two tuning plugins require the same data,only one instance o f the monitoring plugin is created and the data isshared.
Each tuning plugin tunes an individual subsystem and takes severalparameters that are populated from the t uned pro files. Eachsubsystem can have multiple devices (fo r example, multiple CPUs ornetwork cards) that are handled by individual instances o f the tuningplugins. Specific settings for individual devices are also supported. Thesupplied pro files use wildcards to match all devices o f individualsubsystems (for details on how to change this, refer to Section 2.5.4,“Custom Profiles”), which allows the plugins to tune these subsystemsaccording to the required goal (selected pro file) and the only thing thatthe user needs to do is to select the correct t uned pro file (fo r details onhow to select a pro file or fo r a list o f supplied pro files, see Section 2.5.3,“Installation and Usage”). Currently, the fo llowing tuning plugins areimplemented (only some of these plugins implement dynamic tuning,parameters supported by plugins are also listed):
cpu
Sets the CPU governor to the value specified by the governorparameter and dynamically changes the PM QoS CPU DMA latencyaccording to the CPU load. If the CPU load is lower than the valuespecified by the load_threshold parameter, the latency is set tothe value specified by the latency_high parameter, o therwise it isset to value specified by latency_low. Also the latency can beforced to a specific value without being dynamically changed further.This can be accomplished by setting the force_latency parameterto the required latency value.
eeepc_she
Dynamically sets the FSB speed according to the CPU load; thisfeature can be found on some netbooks and is also known as theAsus Super Hybrid Engine. If the CPU load is lower or equal to thevalue specified by the load_threshold_powersave parameter, theplugin sets the FSB speed to the value specified by the she_powersave parameter (fo r details about the FSB frequenciesand corresponding values, see the kernel documentation, theprovided defaults should work for most users). If the CPU load ishigher or equal to the value specified by the load_threshold_normal parameter, it sets the FSB speed to thevalue specified by the she_normal parameter. Static tuning is notsupported and the plugin is transparently disabled if the hardwaresupport fo r this feature is not detected.
net
Configures wake-on-lan to the values specified by the wake_on_lan parameter (it uses same syntax as the et ht o o lutility). It also dynamically changes the interface speed according tothe interface utilization.
sysctl
Sets various sysctl settings specified by the plugin parameters.The syntax is name=value, where name is the same as the name
Fedora 20 Power Management Guide 19
provided by the sysct l too l. Use this plugin if you need to changesettings that are not covered by o ther plugins (but prefer specificplugins if the settings are covered by them).
usb
Sets autosuspend timeout o f USB devices to the value specified bythe autosuspend parameter. The value 0 means that autosuspendis disabled.
vm
Enables or disables transparent huge pages depending on theBoolean value o f the transparent_hugepages parameter.
audio
Sets the autosuspend timeout fo r audio codecs to the valuespecified by the timeout parameter. Currently snd_hda_intel and snd_ac97_codec are supported. The value 0 means that theautosuspend is disabled. You can also enforce the contro ller resetby setting the Boolean parameter reset_controller to true.
disk
Sets the elevator to the value specified by the elevator parameter.It also sets ALPM to the value specified by the alpm parameter (referto Section 3.8, “Aggressive Link Power Management”), ASPM to thevalue specified by the aspm parameter (refer toSection 3.7, “Active-State Power Management”), scheduler quantum to the valuespecified by the scheduler_quantum parameter, disk spindowntimeout to the value specified by the spindown parameter, diskreadahead to the value specified by the readahead parameter, andcan multiply the current disk readahead value by the constantspecified by the readahead_multiply parameter. In addition, thisplugin dynamically changes the advanced power management andspindown timeout setting for the drive according to the current driveutilization. The dynamic tuning can be contro lled by the Booleanparameter dynamic and is enabled by default.
mounts
Enables or disables barriers fo r mounts according to the Booleanvalue o f the disable_barriers parameter.
script
This plugin can be used for the execution o f an external script that isrun when the pro file is loaded or unloaded. The script is called byone argument which can be start o r stop (it depends on whetherthe script is called during the pro file load or unload). The script filename can be specified by the script parameter. Note that youneed to correctly implement the stop action in your script and revertall setting you changed during the start action, o therwise the ro ll-back will no t work. For your convenience, the functions Bashhelper script is installed by default and allows you to import and usevarious functions defined in it. Note that this functionality is providedmainly fo r backwards compatibility and it is recommended that youuse it as the last resort and prefer o ther plugins if they cover therequired settings.
sysfs
Sets various sysfs settings specified by the plugin parameters. Thesyntax is name=value, where name is the sysfs path to use. Usethis plugin in case you need to change some settings that are notcovered by o ther plugins (please prefer specific plugins if they coverthe required settings).
video
Sets various powersave levels on video cards (currently only theRadeon cards are supported). The powersave level can be
20 Chapter 2. Power Management Auditing and Analysis
specified by using the radeon_powersave parameter. Supportedvalues are: default, auto, low, mid, high, and dynpm. For details,refer tohttp://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options.Note that this plugin is experimental and the parameter may changein the future releases.
2.5.2. Provided ProfilesThe fo llowing is a list o f pro files which are installed with the basepackage:
balanced
The default power-saving pro file. It is intended to be a comprimisebetween performance and power consumption. It tries to use auto-scaling and auto-tunning whenever possible. It has good results fo rmost loads. The only drawback is the increased latency. In thecurrent t uned release it enables the CPU, disk, audio and videoplugins and activates the ondemand governor. The radeon_powersave is set to auto.
powersave
A pro file fo r maximum power saving performance. It can thro ttle theperformance in order to minimize the actual power consumption. Inthe current t uned release it enables USB autosuspend, WiFi powersaving and ALPM power savings for SATA host adapters (refer toSection 3.8, “Aggressive Link Power Management”). It alsoschedules multi-core power savings for systems with a low wakeuprate and activates the ondemand governor. It enables AC97 audiopower saving or, depending on your system, HDA-Intel powersavings with a 10 seconds timeout. In case your system containssupported Radeon graphics card with enabled KMS it configures itto automatic power saving. On Asus Eee PCs a dynamic SuperHybrid Engine is enabled.
Note
The powersave pro file may not always be the most efficient.Consider there is a defined amount o f work that needs to bedone, fo r example a video file that needs to be transcoded.Your machine can consume less energy if the transcoding isdone on the full power, because the task will be finishedquickly, the machine will start to idle and can automaticallystep-down to very efficient power save modes. On the o therhand if you transcode the file with a thro ttled machine, themachine will consume less power during the transcoding,but the process will take longer and the overall consumedenergy can be higher. That is why the balanced pro file canbe generally a better option.
throughput-performance
A server pro file optimized for high throughput. It disables powersavings mechanisms and enables sysctl settings that improve thethroughput performance o f the disk, network IO and switched to the deadline scheduler. CPU governor is set to performance.
latency-performance
A server pro file optimized for low latency. It disables power savingsmechanisms and enables sysctl settings that improve the latency.CPU governor is set to performance and the CPU is locked to thelow C states (by PM QoS).
virtual-guest
A pro file designed for virtual guests based on the enterprise-storage pro file that, among o ther tasks, decreases virtual memoryswappiness and increases disk readahead values. It does not
A pro file designed for virtual hosts based on the enterprise-storageprofile that, among o ther tasks, decreases virtual memoryswappiness, increases disk readahead values and enables moreaggresive writeback o f dirty pages.
Additional predefined pro files are available by installing the tuned-profiles-compat package. These pro files are intended for backwardcompatibility and are no longer developed. The generalized pro filesfrom the base package will mostly perform the same or better. If you donot have specific reason for using them, please prefer the abovementioned pro files from the base package. The compat pro files arefo llowing:
default
This has the lowest impact on power saving o f the available pro filesand only enables CPU and disk plugins o f t uned.
desktop-powersave
A power-saving pro file directed at desktop systems. Enables ALPMpower saving for SATA host adapters (refer to Section 3.8,“Aggressive Link Power Management”) as well as the CPU,Ethernet, and disk plugins o f t uned.
server-powersave
A power-saving pro file directed at server systems. Enables ALPMpowersaving for SATA host adapters and activates the CPU anddisk plugins o f t uned.
laptop-ac-powersave
A medium-impact power-saving pro file directed at laptops runningon AC. Enables ALPM powersaving for SATA host adapters, Wi-Fipower saving, as well as the CPU, Ethernet, and disk plugins o ft uned.
laptop-battery-powersave
A high-impact power-saving pro file directed at laptops running onbattery. In the current t uned implementation it is an alias for the powersave pro file.
spindown-disk
A power-saving pro file fo r machines with classic HDDs tomaximize spindown time. It disables the t uned power savingsmechanism, disables USB autosuspend, disables Bluetooth,enables Wi-Fi power saving, disables logs syncing, increases diskwrite-back time, and lowers disk swappiness. All partitions areremounted with the noatime option.
enterprise-storage
A server pro file directed at enterprise-class storage, maximizing I/Othroughput. It activates the same settings as the throughput-performance pro file, multiplies readahead settings, and disablesbarriers on non-root and non-boot partitions.
For more information on the T uned pro files, refer to the tuned-adm(8)manual page.
2.5.3. Installat ion and UsageTo install the tuned package, run, as root, the fo llowing command:
22 Chapter 2. Power Management Auditing and Analysis
yum install tuned
Installation o f the tuned package also presets the pro file which shouldbe the best fo r you system. Currently the default pro file is selectedaccording the fo llowing customizable rules:
throughput-performance
This is pre-selected on Fedora operating systems which act ascompute nodes. The goal on such systems is the best throughputperformance.
virtual-guest
This is pre-selected on virtual machines. The goal is bestperformance. If you are not interested in best performance, youwould probably like to change it to the balanced o r powersaveprofile (see bellow).
balanced
This is pre-selected in all o ther cases. The goal is balancedperformance and power consumption.
To start t uned, run, as root, the fo llowing command:
systemctl start tuned
To enable t uned to start every time the machine boots, type thefo llowing command:
systemctl enable tuned
For o ther t uned contro l such as selection o f pro files and o ther, use:
tuned-adm
This command requires the t uned service to be running.
To view the available installed pro files, run:
tuned-adm list
To view the currently activated pro file, run:
tuned-adm active
To select or activate a pro file, run:
tuned-adm profile profile
For example:
tuned-adm profile powersave
As an experimental feature it is possible to select more pro files at once.The t uned application will try to merge them during the load. If there areconflicts the settings from the last specified pro file will take precedence.This is done automatically and there is no checking whether theresulting combination o f parameters makes sense. If used withoutthinking, the feature may tune some parameters the opposite way whichmay be counterproductive. An example o f such situation would besetting the disk for the high throughput by using the throughput-performance pro file and concurrently setting the disk spindown to the low value by the spindown-disk pro file. The fo llowing exampleoptimizes the system for run in a virtual machine for the bestperformance and concurrently tune it fo r the low power consumptionwhile the low power consumption is the prio rity:
tuned-adm profile virtual-guest powersave
To let t uned recommend you the best suitable pro file fo r your systemwithout changing any existing pro files and using the same logic as usedduring the installation, run the fo llowing command:
Fedora 20 Power Management Guide 23
tuned-adm recommend
T uned itself has additional options that you can use when you run itmanually. However, this is not recommended and is mostly intended fordebugging purposes. The available options can be viewing using thefo llowing command:
tuned --help
2.5.4. Custom ProfilesDistribution-specific pro files are stored in the /usr/lib/tuneddirectory. Each pro file has its own directory. The pro file consists o f themain configuration file called tuned.conf and optionally o ther files likehelper scripts. Do not change the pro files in /usr/lib/tuned. If youneed to customize the pro file, copy the pro file directory to the /etc/tuned directory. This is the place for the custom pro files. If thereare two pro files with the same name, the pro file from /etc/tuned willtake precedence. You can also create your own pro file in the /etc/tuned directory which will include the pro file o f your interest andonly change or override the desired parameters.
The tuned.conf file contains several sections. There is one [main]section. The o ther sections are configurations for plugins instances. Allsections are optional including the [main] section. Comments are alsosupported. Lines starting with a hash (#) are comments.
The [main] section has the fo llowing option:
include=profile
The specified pro file will be included, e.g. include=powersave willinclude the powersave pro file.
Sections describing plugins instances are formatted in the fo llowingway:
[NAME]type=TYPEdevices=DEVICES
NAME is the name of the plugin instance as it is used in the logs. It can bean arbitrary string. TYPE is the type o f the tuning plugin. For a list anddescriptions o f the tuning plugins refer to Section 2.5.1, “Plugins”. DEVICES is the list o f devices this plugin instance will handle. The devices line can contain a list, a wildcard (*), and negation (!). You canalso combine rules. If there is no devices line all devices present orlater attached on the system of the TYPE will be handled by the plugininstance. This is same as using devices=*. If no instance o f the pluginis specified, the plugin will no t be enabled. If the plugin supports moreoptions, they can be also specified in the plugin section. If the option isnot specified, the default value will be used (if no t previously specified inthe included plugin). For the list o f plugin options refer to Section 2.5.1,“Plugins”).
Example 2.1. Describing plugins inst ancesThe fo llowing example will match everything starting with sd, such as sda o r sdb and doesn't disable barriers on them:
24 Chapter 2. Power Management Auditing and Analysis
In cases where you do not need custom names for the plugin instanceand there is only one definition o f the instance in your configuration file,Tuned supports the fo llowing short syntax:
[TYPE]devices=DEVICES
In this case, it is possible to omit the type line. The instance will then bereferred to with a name, same as the type. The previous example couldbe then rewritten into :
[disk]devices=sdb*disable_barriers=false
If the same section is specified more than once using the includeoption, then the settings are merged. If they cannot be merged due to aconflict, the last conflicting definition will override the previous settings inconflict. Sometimes you do not know what was previously defined. Insuch cases, you can use the replace boo lean option and set it to true.This will cause all the previous definitions with the same name to beoverwritten and the merge will no t happen.
You can also disable the plugin by specifying the enabled=falseoption. This has the same effect as if the instance was never defined.Disabling the plugin can be useful if you are redefining the previousdefinition from the include option and do not want the plugin to beactive in your custom pro file.
Most o f the time the device can be handled by one plugin instance. If thedevice matches multiple instances definitions, an error is reported.
The fo llowing is an example o f a custom pro file that is based on the balanced pro file and extends it the way that ALPM for all devices is setto the maximal powersave.
[main]include=balanced
[disk]alpm=min_power
2.5.5. Powertop2tunedThe po wert o p2t uned utility is a too l that allows you to create customt uned pro files from the Po werT OP suggestions. For details aboutPo werT OP refer to Section 2.2, “PowerTOP”).
To install the po wert o p2t uned application, run, as root, the fo llowingcommand:
yum install tuned-utils
To create a custom pro file, run , as root, the fo llowing command:
powertop2tuned new_profile_name
By default it creates the pro file in the /etc/tuned directory and it basesit on the currently selected t uned pro file. For safety reasons allPo werT OP tunings are initially disabled in the new pro file. To enablethem uncomment the tunings o f your interest in the /etc/tuned/profile/tuned.conf. You can use the --enable o r -eoption that will generate the new pro file with most o f the tuningssuggested by Po werT OP enabled. Some dangerous tunings like theUSB autosuspend will still be disabled. If you really need them you willhave to uncomment them manually. By defautl, the new pro file is notactivated. To activate it run the fo llowing command:
tuned-adm profile new_profile_name
For a complete list o f po wert o p2t uned options, type in the fo llowingcommand:
powertop2tuned --help
Fedora 20 Power Management Guide 25
2.6. UPowerIn Fedora 11 DeviceKit -po wer assumed the power managementfunctions that were part o f HAL and some of the functions that were parto f GNOME Po wer Manager in previous releases o f Fedora (refer alsoto Section 2.7, “GNOME Power Manager”. In Fedora 13, DeviceKit -po wer was renamed to UPo wer. UPo wer provides a daemon, an API,and a set o f command-line too ls. Each power source on the system isrepresented as a device, whether it is a physical device or not. Forexample, a laptop battery and an AC power source are both representedas devices.
You can access the command-line too ls with the upower command andthe fo llowing options:
--enumerate, -edisplays an object path for each power devices on the system, forexample:
--dump, -ddisplays the parameters for all power devices on the system.
--wakeups, -wdisplays the CPU wakeups on the system.
--monitor, -mmonitors the system for changes to power devices, fo r example,the connection or disconnection o f a source o f AC power, or thedepletion o f a battery. Press Ctrl+C to stop monitoring the system.
--monitor-detail
monitors the system for changes to power devices, fo r example,the connection or disconnection o f a source o f AC power, or thedepletion o f a battery. The --monitor-detail option presentsmore detail than the --monitor option. Press Ctrl+C to stopmonitoring the system.
--show-info object_path, -i object_pathdisplays all information available for a particular object path. Forexample, to obtain information about a battery on your systemrepresented by the object path /org/freedesktop/UPower/devices/battery_BAT0, run:
2.7. GNOME Power ManagerGNOME Po wer Manager is a daemon that is installed as part o f theGNOME desktop. Much o f the power-management functionality thatGNOME Po wer Manager provided in early releases o f Fedora becamepart o f DeviceKit -po wer in Fedora 11, renamed to UPo wer inFedora 13 (see Section 2.6, “UPower”. However, GNOME Po werManager remains a front end for that functionality. Through an applet inthe system tray, GNOME Po wer Manager no tifies you o f changes inyour system's power status; fo r example, a change from battery to ACpower. It also reports battery status, and warns you when battery poweris low.
2.8. acpidacpid is a daemon that monitors Advanced Configuration and PowerInterface (ACPI) events and executes scripts to respond to them. Theseevents are typically prompted by the user interacting with the hardware,
26 Chapter 2. Power Management Auditing and Analysis
such as closing a laptop lid or pressing the power button.
acpid executes actions based on rules you establish. Certain rules arepredefined on installation but can be altered. These rules are set inconfiguration files created in /etc/acpi/events.
Each file must define an event and an action on separate lines for eachrule. The event= line identifies the hardware interaction to beconfigured. The action= line specifies a shell script containing theconfiguration, which you must create (typically in /etc/acpi/actions).Multiple rules can be set fo r each event, o r one rule for multiple events.
acpid ships with one shell script at /etc/acpi/actions/power.shand two configuration files in /etc/acpi/events: powerconf and videoconf. powerconf is structured as fo llows:
# ACPID config to power down machine if powerbutton is pressed, but only if # no gnome-power-manager is running event=button/power.*action=/etc/acpi/actions/power.sh
acpid is installed by default in some, but not all Fedora installations.
2.9. Other Tools for AuditingFedora 20 o ffers quite a few more too ls with which to perform systemauditing and analysis. Most o f them can be used as supplementarysources o f information in case you want to verify what you havediscovered already or in case you need more in-depth information oncertain parts. Many o f these too ls are used for performance tuning aswell. They include:
vmst atvmst at gives you detailed information about processes, memory,paging, block I/O, traps, and CPU activity. Use it to take a closerlook at what the system overall does and where it is busy.
io st atio st at is similar to vmst at , but only fo r I/O on block devices. Italso provides more verbose output and statistics.
blkt raceblkt race is a very detailed block I/O trace program. It breaks downinformation to single blocks associated with applications. It is veryuseful in combination with diskdevst at .
Fedora 20 Power Management Guide 27
Chapter 3. CoreInfrastructure andMechanics3.1. CPU Idle States
3.2. Using CPUfreq Governors
3.2.1. CPUfreq Governor Types3.2.2. CPUfreq Setup3.2.3. Tuning CPUfreq Po licy and Speed
3.3. CPU Monitors
3.4. CPU Power Saving Po licies
3.5. Suspend and Resume
3.6. Tickless Kernel
3.7. Active-State Power Management
3.8. Aggressive Link Power Management
3.9. Relatime Drive Access Optimization
3.10. Power Capping
3.11. Enhanced Graphics Power Management
3.12. RFKill
3.13. Optimizations in User Space
Package required for cpupower
To use the cpupower command featured in this chapter, ensureyou have the kernel-tools package installed.
3.1. CPU Idle StatesCPUs with the x86 architecture support various states in which parts o fthe CPU are deactivated or run at lower performance settings. Thesestates, known as C-states, allow systems to save power by partiallydeactivating CPUs that are not in use. C-states are numbered from C0upwards, with higher numbers representing decreased CPU functionalityand greater power saving. C-States o f a given number are broadlysimilar across processors, although the exact details o f the specificfeature sets o f the state may vary between processor families. C-States0–3 are defined as fo llows:
C0the operating or running state. In this state, the CPU is working andnot idle at all.
C1, Halta state where the processor is not executing any instructions but istypically not in a lower power state. The CPU can continueprocessing with practically no delay. All processors o ffering C-States need to support this state. Pentium 4 processors support anenhanced C1 state called C1E that actually is a state for lowerpower consumption.
28 Chapter 3. Core Infrastructure and Mechanics
C2, St o p-Clo cka state where the the clock is frozen for this processor but it keepsthe complete state for its registers and caches, so after starting theclock again it can immediately start processing again. This is anoptional state.
C3, Sleepa state where the processor really goes to sleep and does not needto keep its cache up to date. Waking up from this state takesconsiderably longer than from C2 due to this. Again this is anoptional state.
To view available idle states and o ther statistics for the CPUidle driver,run the fo llowing command:
cpupower idle-info
Recent Intel CPUs with the "Nehalem" microarchitecture feature a newC-State, C6, which can reduce the vo ltage supply o f a CPU to zero , buttypically reduces power consumption by between 80% and 90%. Thekernel in Fedora 20 includes optimizations for this new C-State.
3.2. Using CPUfreq GovernorsOne of the most effective ways to reduce power consumption and heatoutput on your system is to use CPUfreq. CPUfreq — also referred to asCPU speed scaling — allows the clock speed o f the processor to beadjusted on the fly. This enables the system to run at a reduced clockspeed to save power. The rules for shifting frequencies, whether to afaster or slower clock speed, and when to shift frequencies, are definedby the CPUfreq governor.
The governor defines the power characteristics o f the system CPU,which in turn affects CPU performance. Each governor has its ownunique behavior, purpose, and suitability in terms o f workload. Thissection describes how to choose and configure a CPUfreq governor,the characteristics o f each governor, and what kind o f workload eachgovernor is suitable for.
The main concerns surrounding power management are:
Heat reduction for servers
Extending battery life fo r laptops
As a rule, lowering the power consumption o f a specific component (oro f the system as a whole) will lead to lower heat and naturally,performance. As such, you should thoroughly study and test thedecrease in performance afforded by any configurations you make,especially fo r mission-critical systems.
The fo llowing sections explain how optimal hardware performancebenefits your system in terms o f energy consumption.
3.2.1. CPUfreq Governor TypesThis section lists and describes the different types o f CPUfreqgovernors available in Fedora 20.
cpufreq_perfo rmance
The Performance governor fo rces the CPU to use the highest possibleclock frequency. This frequency will be statically set, and will no t change.As such, this particular governor o ffers no power saving benefit. It is onlysuitable for hours o f heavy workload, and even then only during timeswherein the CPU is rarely (or never) idle.
cpufreq_po wersave
By contrast, the Powersave governor fo rces the CPU to use the lowestpossible clock frequency. This frequency will be statically set, and will
Fedora 20 Power Management Guide 29
not change. As such, this particular governor o ffers maximum powersavings, but at the cost o f the lowest CPU performance.
The term "powersave" can sometimes be deceiving, though, since (inprinciple) a slow CPU on full load consumes more power than a fastCPU that is not loaded. As such, while it may be advisable to set theCPU to use the Powersave governor during times o f expected lowactivity, any unexpected high loads during that time can cause thesystem to actually consume more power.
The Powersave governor is, in simple terms, more o f a "speed limiter"for the CPU than a "power saver". It is most useful in systems andenvironments where overheating can be a problem.
cpufreq_o ndemand
The Ondemand governor is a dynamic governor that allows the CPU toachieve maximum clock frequency when system load is high, and alsominimum clock frequency when the system is idle. While this allows thesystem to adjust power consumption accordingly with respect tosystem load, it does so at the expense o f latency between frequencyswitching. As such, latency can o ffset any performance/power savingbenefits o ffered by the Ondemand governor if the system switchesbetween idle and heavy workloads too o ften.
For most systems, the Ondemand governor can provide the bestcompromise between heat emission, power consumption,performance, and manageability. When the system is only busy atspecific times o f the day, the Ondemand governor will automaticallyswitch between maximum and minimum frequency depending on theload without any further intervention.
cpufreq_userspace
The Userspace governor allows userspace programs (or any processrunning as root) to set the frequency. Of all the governors, Userspace isthe most customizable; and depending on how it is configured, it canoffer the best balance between performance and consumption for yoursystem.
cpufreq_co nservat ive
Like the Ondemand governor, the Conservative governor also adjuststhe clock frequency according to usage (like the Ondemand governor).However, while the Ondemand governor does so in a more aggressivemanner (that is from maximum to minimum and back), the Conservativegovernor switches between frequencies more gradually.
This means that the Conservative governor will adjust to a clockfrequency that it deems fitting for the load, rather than simply choosingbetween maximum and minimum. While this can possibly providesignificant savings in power consumption, it does so at an ever greaterlatency than the Ondemand governor.
Note
You can enable a governor using cron jobs. This allows you toautomatically set specific governors during specific times o f theday. As such, you can specify a low-frequency governor duringidle times (for example after work hours) and return to a higher-frequency governor during hours o f heavy workload.For instructions on how to enable a specific governor, refer toSection 3.2.2, “CPUfreq Setup”.
3.2.2. CPUfreq SetupAll CPUfreq drivers are built in and selected automatically, so to set upCPUfreq you just need to select a governor.
You can view which governors are available for use for a specific CPUusing:
30 Chapter 3. Core Infrastructure and Mechanics
cpupower frequency-info --governors
You can then enable one o f these governors on all CPUs using:
cpupower frequency-set --governor [governor]
To only enable a governor on specific cores, use -c with a range orcomma-separated list o f CPU numbers. For example, to enable theUserspace governor fo r CPUs 1-3 and 5, the command would be:
3.2.3. Tuning CPUfreq Policy and SpeedOnce you have chosen an appropriate CPUfreq governor, you can viewCPU speed and po licy information with the cpupower frequency-infocommand and further tune the speed o f each CPU with options for cpupower frequency-set.
For cpupower frequency-info, the fo llowing options are available:
--freq — Shows the current speed o f the CPU according to theCPUfreq core, in KHz.
--hwfreq — Shows the current speed o f the CPU according to thehardware, in KHz (only available as root).
--driver — Shows what CPUfreq driver is used to set the frequencyon this CPU.
--governors — Shows the CPUfreq governors available in thiskernel. If you wish to use a CPUfreq governor that is not listed in thisfile, refer to Section 3.2.2, “CPUfreq Setup” fo r instructions on how todo so.
--affected-cpus — Lists CPUs that require frequencycoordination software.
--policy — Shows the range o f the current CPUfreq po licy, in KHz,and the currently active governor.
--hwlimits — Lists available frequencies for the CPU, in KHz.
For cpupower frequency-set, the fo llowing options are available:
--min <freq> and --max <freq> — Set the policy limits o f theCPU, in KHz.
Important
When setting po licy limits, you should set --max before --min.
--freq <freq> — Set a specific clock speed for the CPU, in KHz.You can only set a speed within the po licy limits o f the CPU (as per --min and --max).
--governor <gov> — Set a new CPUfreq governor.
Alternative to cpupower
If you do not have the kernel-tools package installed, CPUfreqsettings can be viewed in the tunables found in /sys/devices/system/cpu/[cpuid]/cpufreq/. Settings andvalues can be changed by writing to these tunables. For example,to set the minimum clock speed o f cpu0 to 360 KHz, use:
cpupo wer features a selection o f monitors that provide idle and sleepstate statistics and frequency information and report on processortopo logy. Some monitors are processor-specific, while o thers arecompatible with any processor. Refer to the cpupower-monitor manpage for details on what each monitor measures and which systemsthey are compatible with.
Use the fo llowing options with the cpupower monitor command:
-l — list all monitors available on your system.
-m <monitor1>, <monitor2> — display specific monitors. Theiridentifiers can be found by running -l.
command — display the idle statistics and CPU demands o f a specificcommand.
3.4. CPU Power Saving Policiescpupo wer provides ways to regulate your processor's power savingpo licies.
Use the fo llowing options with the cpupower set command:
--perf-bias <0-15>Allows software on supported Intel processors to more activelycontribute to determining the balance between optimumperformance and saving power. This does not override o ther powersaving po licies. Assigned values range from 0 to 15, where 0 isoptimum performance and 15 is optimum power efficiency.
By default, this option applies to all cores. To apply it only toindividual cores, add the --cpu <cpulist> option.
--sched-mc <0|1|2>Restricts the use o f power by system processes to the cores in oneCPU package before o ther CPU packages are drawn from. 0 setsno restrictions, 1 initially employs only a single CPU package, and 2does this in addition to favouring semi-idle CPU packages forhandling task wakeups.
--sched-smt <0|1|2>Restricts the use o f power by system processes to the threadsiblings o f one CPU core before drawing on o ther cores. 0 sets norestrictions, 1 initially employs only a single CPU package, and 2does this in addition to favouring semi-idle CPU packages forhandling task wakeups.
3.5. Suspend and ResumeWhen a system is suspended, the kernel calls on drivers to store theirstates and then unloads them. When the system is resumed, it reloadsthese drivers, which attempt to reprogram their devices. The drivers'ability to accomplish this task determines whether the system can beresumed successfully.
Video drivers are particularly problematic in this regard, because theAdvanced Configuration and Power Interface (ACPI) specification doesnot require system firmware to be able to reprogram video hardware.Therefore, unless video drivers are able to program hardware from acompletely uninitialized state, they may prevent the system fromresuming.
Fedora 20 includes greater support fo r new graphics chipsets, whichensures that suspend and resume will work on a greater number o fplatforms.
3.6. Tickless KernelPreviously, the Linux kernel periodically interrupted each CPU on asystem at a predetermined frequency — 100 Hz, 250 Hz, or 1000 Hz,
32 Chapter 3. Core Infrastructure and Mechanics
depending on the platform. The kernel queried the CPU about theprocesses that it was executing, and used the results fo r processaccounting and load balancing. Known as the timer tick, the kernelperformed this interrupt regardless o f the power state o f the CPU.Therefore, even an idle CPU was responding to up to 1000 o f theserequests every second. On systems that implemented power savingmeasures for idle CPUs, the timer tick prevented the CPU fromremaining idle long enough for the system to benefit from these powersavings.
The kernel in Fedora 20 runs tickless: that is, it replaces the o ld periodictimer interrupts with on-demand interrupts. Therefore, idle CPUs areallowed to remain idle until a new task is queued for processing, andCPUs that have entered lower power states can remain in these stateslonger.
3.7. Active-State Power ManagementActive-State Power Management (ASPM) saves power in the PeripheralComponent Interconnect Express (PCI Express or PCIe) subsystem bysetting a lower power state for PCIe links when the devices to which theyconnect are not in use. ASPM contro ls the power state at both ends o fthe link, and saves power in the link even when the device at the end o fthe link is in a fully powered-on state.
When ASPM is enabled, device latency increases because o f the timerequired to transition the link between different power states. ASPM hasthree po licies to determine power states:
defaultsets PCIe link power states according to the defaults specified bythe firmware on the system (for example, BIOS). This is the defaultstate for ASPM.
po wersavesets ASPM to save power wherever possible, regardless o f the costto performance.
perfo rmancedisables ASPM to allow PCIe links to operate with maximumperformance.
ASPM po licies are set in /sys/module/pcie_aspm/parameters/policy, but can also bespecified at boot time with the pcie_aspm kernel parameter, where pcie_aspm=off disables ASPM and pcie_aspm=force enables ASPM,even on devices that do not support ASPM.
Warning — pcie_aspm=force can causesystems to stop responding
If pcie_aspm=force is set, hardware that does not supportASPM can cause the system to stop responding. Before setting pcie_aspm=force, ensure that all PCIe hardware on the systemsupports ASPM.
3.8. Aggressive Link Power ManagementAggressive Link Power Management (ALPM) is a power-savingtechnique that helps the disk save power by setting a SATA link to thedisk to a low-power setting during idle time (that is when there is no I/O).ALPM automatically sets the SATA link back to an active power stateonce I/O requests are queued to that link.
Power savings introduced by ALPM come at the expense o f disklatency. As such, you should only use ALPM if you expect the system toexperience long periods o f idle I/O time.
Fedora 20 Power Management Guide 33
ALPM is only available on SATA contro llers that use the Advanced HostController Interface (AHCI). For more information about AHCI, refer tohttp://www.intel.com/techno logy/serialata/ahci.htm.
When available, ALPM is enabled by default. ALPM has three modes:
min_po wer
This mode sets the link to its lowest power state (SLUMBER) whenthere is no I/O on the disk. This mode is useful fo r times when anextended period o f idle time is expected.
medium_po wer
This mode sets the link to the second lowest power state (PARTIAL)when there is no I/O on the disk. This mode is designed to allowtransitions in link power states (fo r example during times o f intermittentheavy I/O and idle I/O) with as small impact on performance aspossible.
medium_power mode allows the link to transition between PARTIAL andfully-powered (that is "ACTIVE") states, depending on the load. Note thatit is not possible to transition a link directly from PARTIAL to SLUMBERand back; in this case, either power state cannot transition to the o therwithout transitioning through the ACTIVE state first.
max_perfo rmance
ALPM is disabled; the link does not enter any low-power state whenthere is no I/O on the disk.
To check whether your SATA host adapters actually support ALPM youcan check if the file /sys/class/scsi_host/host*/link_power_management_policyexists. To change the settings simply write the values described in thissection to these files or display the files to check for the current setting.
Important — some settings disable hotplugging
Setting ALPM to min_power o r medium_power will automaticallydisable the "Hot Plug" feature.
3.9. Relatime Drive Access OptimizationThe POSIX standard requires that operating systems maintain filesystem metadata that records when each file was last accessed. Thistimestamp is called atime, and maintaining it requires a constant seriesof write operations to storage. These writes keep storage devices andtheir links busy and powered up. Since few applications make use o f theatime data, this storage device activity wastes power. Significantly, thewrite to storage would occur even if the file was not read from storage,but from cache. For some time, the Linux kernel has supported a noatime option for mo unt and would not write atime data to filesystems mounted with this option. However, simply turning o ff thisfeature is problematic because some applications rely on atime dataand will fail if it is not available.
The kernel used in Fedora 20 supports another alternative — relatime.Relatime maintains atime data, but not fo r each time that a file isaccessed. With this option enabled, atime data is written to the diskonly if the file has been modified since the atime data was last updated(mtime), o r if the file was last accessed more than a certain length o ftime ago (by default, one day).
By default, all filesystems are now mounted with relatime enabled.You can suppress it fo r any particular file system by mounting that filesystem with the option norelatime.
3.10. Power CappingFedora 20 supports the power capping features found in recenthardware, such as HP Dynamic Power Capping (DPC), and Intel NodeManager (NM) techno logy. Power capping allows administrators to limitthe power consumed by servers, but it also allows managers to plandata centers more efficiently, because the risk o f overloading existingpower supplies is greatly diminished. Managers can place more serverswithin the same physical foo tprint and have confidence that if serverpower consumption is capped, the demand for power during heavy loadwill no t exceed the power available.
HP Dynamic Po wer Capping
Dynamic Power Capping is a feature available on select ProLiant andBladeSystem servers that allows system administrators to cap thepower consumption o f a server or a group o f servers. The cap is adefinitive limit that the server will no t exceed, regardless o f its currentworkload. The cap has no effect until the server reaches its powerconsumption limit. At that po int, a management processor adjusts CPUP-states and clock thro ttling to limit the power consumed.
Dynamic Power Capping modifies CPU behavior independently o f theoperating system, however, HP's integrated Lights-Out 2 (iLO2) firmwareallows operating systems access to the management processor andtherefore applications in user space can query the managementprocessor. The kernel used in Fedora 20 includes a driver fo r HP iLOand iLO2 firmware, which allows programs to query managementprocessors at /dev/hpilo/dXccbN. The kernel also includes anextension o f the hwmon sysfs interface to support power cappingfeatures, and a hwmon driver fo r ACPI 4.0 power meters that use the sysfs interface. Together, these features allow the operating systemand user-space too ls to read the value configured for the power cap,together with the current power usage o f the system.
For further details o f HP Dynamic Power Capping, refer to HP PowerCapping and HP Dynamic Power Capping for ProLiant Servers, availablefromhttp://h20000.www2.hp.com/bc/docs/support/SupportManual/c01549455/c01549455.pdf
Int e l No de Manager
Intel Node Manager imposes a power cap on systems, using processorP-states and T-states to limit CPU performance and therefore powerconsumption. By setting a power management po licy, administratorscan configure systems to consume less power during times whensystem loads are low, fo r example, at night or on weekends.
Intel Node Manager adjusts CPU performance using Operating System-directed configuration and Power Management (OSPM) through thestandard Advanced Configuration and Power Interface. When Intel NodeManager notifies the OSPM driver o f changes to T-states, the drivermakes corresponding changes to processor P-states. Similarly, whenIntel Node Manager notifies the OSPM driver o f changes to P-states, thedriver changes T-states accordingly. These changes happenautomatically and require no further input from the operating system.Administrators configure and monitor Intel Node Manager with Intel DataCenter Manager (DCM) software.
For further details o f Intel Node Manager, refer to Node Manager — ADynamic Approach To Managing Power In The Data Center, availablefrom http://communities.intel.com/docs/DOC-4766
3.11. Enhanced Graphics PowerManagementFedora 20 saves power on graphics and display devices by eliminatingseveral sources o f unnecessary consumption.
LVDS reclo cking
Low-voltage differential signaling (LVDS) is a system for carrying
electronic signals over copper wire. One significant application o f thesystem is to transmit pixel information to liquid crystal display (LCD)screens in notebook computers. All displays have a refresh rate — therate at which they receive fresh data from a graphics contro ller andredraw the image on the screen. Typically, the screen receives freshdata sixty times per second (a frequency o f 60 Hz). When a screen and agraphics contro ller are linked by LVDS, the LVDS system uses poweron every refresh cycle. When idle, the refresh rate o f many LCD screenscan be dropped to 30 Hz without any noticeable effect (unlike cathoderay tube (CRT) monitors, where a decrease in refresh rate produces acharacteristic flicker). The driver fo r Intel graphics adapters built into thekernel used in Fedora 20 performs this down-clocking automatically,and saves around 0.5 W when the screen is idle.
Enabling memo ry self-refresh
Synchronous dynamic random access memory (SDRAM) — as used forvideo memory in graphics adapters — is recharged thousands o f timesper second so that individual memory cells retain the data that is storedin them. Apart from its main function o f managing data as it flows in andout o f memory, the memory contro ller is normally responsible forinitiating these refresh cycles. However, SDRAM also has a low-powerself-refresh mode. In this mode, the memory uses an internal timer togenerate its own refresh cycles, which allows the system to shut downthe memory contro ller without endangering data currently held inmemory. The kernel used in Fedora 20 can trigger memory self-refreshin Intel graphics adapters when they are idle, which saves around 0.8 W.
GPU clo ck reduct io n
Typical graphical processing units (GPUs) contain internal clocks thatgovern various parts o f their internal circuitry. The kernel used inFedora 20 can reduce the frequency o f some of the internal clocks inIntel and ATI GPUs. Reducing the number o f cycles that GPUcomponents perform in a given time saves the power that they wouldhave consumed in the cycles that they did not have to perform. Thekernel automatically reduces the speed o f these clocks when the GPU isidle, and increases it when GPU activity increases. Reducing GPU clockcycles can save up to 5 W.
GPU po wer-do wn
The Intel and ATI graphics drivers in Fedora 20 can detect when nomonitor is attached to an adapter and therefore shut down the GPUcompletely. This feature is especially significant fo r servers which do nothave monitors attached to them regularly.
3.12. RFKillMany computer systems contain radio transmitters, including Wi-Fi,Bluetooth, and 3G devices. These devices consume power, which iswasted when the device is not in use.
RFKill is a subsystem in the Linux kernel that provides an interfacethrough which radio transmitters in a computer system can be queried,activated, and deactivated. When transmitters are deactivated, they canbe placed in a state where software can reactive them (a soft block) o rwhere software cannot reactive them (a hard block).
The RFKill core provides the application programming interface (API) fo rthe subsystem. Kernel drivers that have been designed to support RFkilluse this API to register with the kernel, and include methods for enablingand disabling the device. Additionally, the RFKill core providesnotifications that user applications can interpret and ways for userapplications to query transmitter states.
The RFKill interface is located at /dev/rfkill, which contains thecurrent state o f all radio transmitters on the system. Each device has itscurrent RFKill state registered in sysfs. Additionally, RFKill issuesuevents fo r each change o f state in an RFKill-enabled device.
Rfkill is a command-line too l with which you can query and changeRFKill-enabled devices on the system. To obtain the too l, install the rfkill
36 Chapter 3. Core Infrastructure and Mechanics
package.
Use the command rfkill list to obtain a list o f devices, each o fwhich has an index number associated with it, starting at 0. You can usethis index number to tell rfkill to block or unblock a device, fo r example:
rfkill block 0
blocks the first RFKill-enabled device on the system.
You can also use rfkill to block certain categories o f devices, or allRFKill-enabled devices. For example:
rfkill block wifi
blocks all Wi-Fi devices on the system. To block all RFKill-enableddevices, run:
rfkill block all
To unblock devices, run rfkill unblock instead o f rfkill block. Toobtain a full list o f device categories that rfkill can block, run rfkill help
3.13. Optimizations in User SpaceReducing the amount o f work performed by system hardware isfundamental to saving power. Therefore, although the changesdescribed in Chapter 3, Core Infrastructure and Mechanics permit thesystem to operate in various states o f reduced power consumption,applications in user space that request unnecessary work from systemhardware prevent the hardware from entering those states. During thedevelopment o f Fedora 20, audits were undertaken in the fo llowingareas to reduce unnecessary demands on hardware:
Reduced wakeups
Fedora 20 uses a tickless kernel (refer to Section 3.6, “Tickless Kernel”),which allows the CPUs to remain in deeper idle states longer. However,the timer tick is not the only source o f excessive CPU wakeups, andfunction calls from applications can also prevent the CPU from enteringor remaining in idle states.
Reduced st o rage and net wo rk IO
Input or output (IO) to storage devices and network interfaces forcesdevices to consume power. In storage and network devices that featurereduced power states when idle (fo r example, ALPM or ASPM), thistraffic can prevent the device from entering or remaining in an idle state,and can prevent hard drives from spinning down when not in use.Excessive and unnecessary demands on storage have been minimizedin several applications. In particular, those demands that prevented harddrives from spinning down.
Init script audit
Services that start automatically whether required or not have greatpotential to waste system resources. Services instead should default to"o ff" o r "on demand" wherever possible. For example, the BlueZservice that enables Bluetooth support previously ran automaticallywhen the system started, whether Bluetooth hardware was present ornot. The BlueZ initscript now checks that Bluetooth hardware is presenton the system before starting the service.
Fedora 20 Power Management Guide 37
Chapter 4. Use Cases4.1. Example — Server
4.2. Example — Laptop
This chapter describes two types o f use case to illustrate the analysisand configuration methods described elsewhere in this guide. The firstexample considers typical servers and the second is a typical laptop.
4.1. Example — ServerA typical standard server nowadays comes with basically all o f thenecessary hardware features supported in Fedora 20. The first thing totake into consideration is the kinds o f workloads for which the serverwill mainly be used. Based on this information you can decide whichcomponents can be optimized for power savings.
Regardless o f the type o f server, graphics performance is generally notrequired. Therefore, GPU power savings can be left turned on.
Webserver
A webserver needs network and disk I/O. Depending on the externalconnection speed 100 Mbit/s might be enough. If the machine servesmostly static pages, CPU performance might not be very important.Power-management cho ices might therefore include:
no disk or network plugins for t uned.
ALPM turned on.
ondemand governor turned on.
network card limited to 100 Mbit/s.
Co mput e server
A compute server mainly needs CPU. Power management cho icesmight include:
depending on the jobs and where data storage happens, disk ornetwork plugins for t uned; o r fo r batch-mode systems, fully activet uned.
depending on utilization, perhaps the performance governor.
Mailserver
A mailserver needs mostly disk I/O and CPU. Power managementcho ices might include:
ondemand governor turned on, because the last few percent o f CPUperformance are not important.
no disk or network plugins for t uned.
network speed should not be limited, because mail is o ften internaland can therefore benefit from a 1 Gbit/s or 10 Gbit/s link.
Fileserver
Fileserver requirements are similar to those o f a mailserver, butdepending on the pro toco l used, might require more CPU performance.Typically, Samba-based servers require more CPU than NFS, and NFStypically requires more than iSCSI. Even so, you should be able to usethe ondemand governor.
Direct o ry server
A directory server typically has lower requirements for disk I/O,especially if equipped with enough RAM. Network latency is importantalthough network I/O less so. You might consider latency network tuning
38 Chapter 4. Use Cases
with a lower link speed, but you should test this carefully fo r yourparticular network.
4.2. Example — LaptopOne other very common place where power management and savingscan really make a difference are laptops. As laptops by design normallyalready use drastically less energy than workstations or servers thepotential fo r abso lute savings are less than for o ther machines. When inbattery mode, though, any saving can help to get a few more minutes o fbattery life out o f a laptop. Although this section focuses on laptops inbattery mode, but you certainly can still use some or all o f those tuningswhile running on AC power as well.
Savings for single components usually make a bigger relative differenceon laptops than they do on workstations. For example, a 1 Gbit/snetwork interface running at 100 Mbits/s saves around 3–4 watts. For atypical server with a to tal power consumption o f around 400 watts, thissaving is approximately 1 %. On a laptop with a to tal powerconsumption o f around 40 watts, the power saving on just this onecomponent amounts to 10 % of the to tal.
Specific power-saving optimizations on a typical laptop include:
Configure the system BIOS to disable all hardware that you do notuse. For example, parallel o r serial ports, card readers, webcams,Wi-Fi, and Bluetooth just to name a few possible candidates.
Dim the display in darker environments where you do not need fullillumination to read the screen comfortably. On the GNOME desktop,use Applicat io ns+Syst em T o o ls → Syst em Set t ings, thenselect Hardware → Po wer. On the KDE desktop, use Kicko ffApplicat io n Launcher+Co mput er+Syst emSet t ings+Advanced → Po wer Management . Alternatively, entergno me-po wer-manager o r xbacklight at the command line oruse the function keys on your laptop.
Use the laptop-battery-powersave pro file o f t uned-adm toenable a whole set o f power-saving mechanisms. Note thatperformance and latency for the hard drive and network interface areimpacted.
Additionally (or alternatively) you can perform many small adjustmentsto various system settings:
use the ondemand governor (enabled by default in Fedora 20)
enable laptop mode (part o f the laptop-battery-powersaveprofile):
echo 5 > /proc/sys/vm/laptop_mode
increase flush time to disk (part o f the laptop-battery-powersaveprofile):
mount filesystem using relatime (default in Fedora 20):
mount -o remount,relatime mountpoint
activate best power saving mode for hard drives (part o f the laptop-battery-powersave pro file):
hdparm -B 1 -S 200 /dev/sd*
reduce screen brightness to 50 o r less, fo r example:
xbacklight -set 50
activate DPMS for screen idle:
xset +dpms; xset dpms 0 0 300
reduce Wi-Fi power levels (part o f the laptop-battery-powersaveprofile):
for i in /sys/bus/pci/devices/*/power_level ; do echo 5 > $i ; done
deactivate Wi-Fi:
echo 1 > /sys/bus/pci/devices/*/rf_kill
limit wired network to 100 Mbit/s (part o f the laptop-battery-powersave pro file):
ethtool -s eth0 advertise 0x0F
Tips for DevelopersEvery good programming textbook covers problems with memoryallocation and the performance o f specific functions. As you developyour software, be aware o f issues that might increase powerconsumption on the systems on which the software runs. Althoughthese considerations do not affect every line o f code, you can optimizeyour code in areas which are frequent bottlenecks for performance.
Some techniques that are o ften problematic include:
using threads.
unnecessary CPU wake-ups and not using wake-ups efficiently. Ifyou must wake up, do everything at once (race to idle) and as quicklyas possible.
using [f]sync() unnecessarily.
unnecessary active po lling or using short, regular timeouts. (Reactto events instead).
not using wake-ups efficiently.
inefficient disk access. Use large buffers to avo id frequent diskaccess. Write one large block at a time.
inefficient use o f timers. Group timers across applications (or evenacross systems) if possible.
excessive I/O, power consumption, or memory usage (includingmemory leaks)
performing unnecessary computation.
The fo llowing sections examine some of these areas in greater detail.
40 Tips for Developers
A.1. Using ThreadsIt is widely believed that using threads makes applications performbetter and faster, but this is not true in every case.
Pyt ho n
Python uses the Global Lock Interpreter, so threading is pro fitable onlyfor larger I/O operations. Unladen-swallo w is a faster implementationof Python with which you might be able to optimize your code.
Perl
Perl threads were originally created for applications running on systemswithout fo rking (such as systems with 32-bit Windows operatingsystems). In Perl threads, the data is copied for every single thread(Copy On Write). Data is not shared by default, because users shouldbe able to define the level o f data sharing. For data sharing thet hreads::shared module has to be included. However, data is not onlythen copied (Copy On Write), but the module also creates tied variablesfor the data, which takes even more time and is even slower.
C
C threads share the same memory, each thread has its own stack, andthe kernel does not have to create new file descriptors and allocate newmemory space. C can really use the support o f more CPUs for morethreads. Therefore, to maximize the performance o f your threads, use alow-level language like C or C++. If you use a scripting language,consider writing a C binding. Use pro filers to identify poorly performingparts o f your code.
A.2. Wake-upsMany applications scan configuration files for changes. In many cases,the scan is performed at a fixed interval, fo r example, every minute. Thiscan be a problem, because it fo rces a disk to wake up from spindowns.The best so lution is to find a good interval, a good checkingmechanism, or to check for changes with ino t ify and react to events.Ino t ify can check variety o f changes on a file or a directory.
int main(int argc, char *argv[]) { int fd; int wd; int retval; struct timeval tv;
fd = inotify_init();
/* checking modification of a file - writing into */ wd = inotify_add_watch(fd, "./myConfig", IN_MODIFY); if (wd < 0) { printf("inotify cannot be used\n"); /* switch back to previous checking */ }
The advantage o f this approach is the variety o f checks that you canperform.
The main limitation is that only a limited number o f watches areavailable on a system. The number can be obtained from /proc/sys/fs/inotify/max_user_watches and although it can bechanged, this is not recommended. Furthermore, in case ino t ify fails,the code has to fall back to a different check method, which usuallymeans many occurrences o f #if #define in the source code.
For more information on ino t ify, refer to the inotify man page.
A.3. FsyncFsync is known as an I/O expensive operation, but this is is notcompletely true.
Firefo x used to call the sqlit e library each time the user clicked on alink to go to a new page. Sqlit e called fsync and because o f the filesystem settings (mainly ext3 with data-ordered mode), there was a longlatency when nothing happened. This could take a long time (up to 30seconds) if another process was copying a large file at the same time.
However, in o ther cases, where fsync was not used at all, problemsemerged with the switch to the ext4 file system. Ext3 was set to data-ordered mode, which flushed memory every few seconds and saved itto a disk. But with ext4 and laptop_mode, the interval between saveswas longer and data might get lost when the system was unexpectedlyswitched o ff. Now ext4 is patched, but we must still consider the designof our applications carefully, and use fsync as appropriate.
The fo llowing simple example o f reading and writing into a configurationfile shows how a backup o f a file can be made or how data can be lost:
42 Tips for Developers
/* open and read configuration file e.g. ./myconfig */fd = open("./myconfig", O_RDONLY);read(fd, myconfig_buf, sizeof(myconfig_buf));close(fd);...fd = open("./myconfig", O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR);write(fd, myconfig_buf, sizeof(myconfig_buf));close(fd);
