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:

kern.*    /var/log/kern.log

This line tells syslogd to call fsync() after every log message matching kern.*. If you change the line to this:

kern.*    -/var/log/kern.log

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.