Kernel Korner - Extending Battery Life with Laptop Mode
To set up Laptop Mode on your system, first make sure you have a kernel version that supports it. Laptop Mode is included in Linux 2.6 from version 2.6.6 upward. In the kernel source tree, you can find the documentation for Laptop Mode in Documentation/laptop-mode.txt. Embedded in the documentation is the control script, which you have to extract and save as /sbin/laptop_mode. Give the script execute permissions: chmod 700 /sbin/laptop_mode.
To enable Laptop Mode, run (as root) /sbin/laptop_mode start. This does everything necessary, except it doesn't make your hard drive spin down. To do that, you must set the hard drive's idle timeout using hdparm -S 4 /dev/hda. The value 4 indicates an idle timeout of 20 seconds. If you want to disable Laptop Mode, simply run /sbin/laptop_mode stop.
You probably want to configure Laptop Mode so it starts whenever your laptop runs on batteries. If you have a laptop that supports ACPI, you can set this up like so: extract the files ac_adapter and battery.sh from the Laptop Mode documentation and install them in the indicated locations. Edit battery.sh to configure your hard drive's device name and your preferred idle timeout, and you're ready to roll.
Sometimes your drive spins up for reasons you don't understand. When this occurs, it's time to start debugging. Laptop Mode includes a mode for debugging disk activity, block dump mode. Before you enable it, you first must stop syslogd from logging kernel messages or stop it completely. How this is done depends on your distribution. If you don't stop syslogd, you may put your machine in an endless loop; the debug output is picked up by syslogd, which writes it to disk, causing more debug output and so forth.
To enable block dump mode, run (as root) echo 1 > /proc/sys/vm/block_dump. The kernel output, which you now have to read using dmesg because syslogd is inactive, should show messages such as these:
bash(273): READ block 3242 on hda1 bash(273): dirtied inode 10237 (.bash_history) on hda1 pdflush(6): WRITE block 3242 on hda1
You can read this output as follows. A process named bash, with process ID 273, has read the block with number 3242 on device /dev/hda1. That same process then dirtied a file called .bash_history; the file was changed, but the changes weren't written to disk yet. The pdflush dæmon then wrote block 3242, which most probably is the block that bash modified earlier.
When you've got the debug output, it's time to diagnose your problem. If you're seeing a READ message somewhere, you don't have to look further. Find out why the process needs to read this data and decide whether you want to stop the process, change the application's settings so that it doesn't need that data anymore or perhaps read the data ahead when the drive is spun up. Reading a file ahead is no more difficult than doing cat /my/file >/dev/null, preferably twice, so Linux's read-once logic does not throw the file right out again. Now, if you're seeing only dirtied file messages, there's not much to worry about. Nobody is writing anything to disk; these messages tell you only that a process is making changes that need to be written eventually. If you get these, your disk spins up once every ten minutes to write back the modifications, and that's it.
If you're seeing WRITE messages more often than once every ten minutes, and you're not seeing any READs that could have triggered an active period, there's a good chance that some process is syncing a file explicitly. syslogd is notorious for doing this. If you see syslogd writing at unexpected times, you should adjust your syslog.conf. It probably contains lines like this one:
This line tells syslogd to call fsync() after every log message matching kern.*. If you change the line to this:
and restart syslog, syslog no longer calls fsync() on these log messages. Be careful for which log files you make this change, though. For instance, if you care about security, you probably want to keep auth.log synchronized.
Tips and Tricks
If you want to play MP3s with your drive suspended, you can try increasing the READAHEAD setting in /sbin/laptop_mode. Alternatively, you can copy a whole set of MP3s to a small tmpfs RAM disk. Make sure you don't make the RAM disk so big that it gets pushed out to swap space or you defeat the purpose. A small RAM disk is good for anything for which you don't want disk activity to occur—but only if your data isn't important.
Custom Spindown Times
It's possible to adjust Laptop Mode's maximum spindown time. To do that, set variable MAX_AGE in /sbin/laptop_mode to the maximum number of seconds you want your data to remain in memory without being saved to disk. By default, it is set to 600 seconds or ten minutes. It really doesn't pay to increase the setting to a higher number, as you can see from the benchmark results that I got on the PowerBook. You can set it to a lower value if you care more about your data and less about those extra two minutes. And if you want to prevent losing some really important data that you've just saved, you simply can execute sync. Laptop Mode respects your sync requests, so this actually writes everything to disk, as it normally would. The sync also resets all timeouts, so that after the sync the disk can stay spun down for up to ten minutes again.
Spinning Down with cpudyn
If you are using cpudyn to control your CPU frequency dynamically, you might be interested to know that it also can spin down your hard drive. I have seen some drives that simply ignore their idle timeout setting if it's too low for their taste. Also, idle timeout settings are done in five-second increments, which means that you can't set it to something like eight seconds. cpudyn comes in handy, because it doesn't rely on your hard drive to detect idle periods, and it can spin it down whenever you want.
Laptop Mode performs a sync at the end of an active period and then waits for the disk to spin down on its own. It's even better to sync just before the drive spins down, because then you save data that is up to 20 seconds more recent. Laptop Mode can't do this, because it can't spin down the drive actively. I have written a script to do this called Smart Spindown, which works together with Laptop Mode. It's an unpolished piece of script, but if you really want to save every bit of power there is or if you want to keep 20 extra seconds of data safe, this might be for you; see the on-line Resources section.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development