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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide