For a long time, hibernation has been associated with proprietary operating systems. Now, the feature has started taking the front row in GNU/Linux systems too. What’s more, it’s fast, flexible and is a real time saver!

Introduction

Software hibernation or suspend-to-disk is a very productive operating system feature. It has many advantages over a cold system start or reboot. Not only does the hibernated system load up faster, the user also gets back to his previous session without much effort. This is important because of the time the user saves by avoiding the need to set up a work session again.

So, how is hibernation different? It is different because it saves the contents of the RAM (Random Access Memory) into some non-volatile storage medium before shutting down the system. Consequently, when the system boots up again, the operating system loads the suspended image from disk to get back to the previously stored session.

Software suspend, as hibernation is popularly known in Linux systems, has evolved a lot in present day kernels. It is constantly getting more and more stable and useful. Some implementations are available in the kernel while one is available as a patch that can be applied to the 2.4 or the 2.6 series. This article is meant to introduce you to the implementations available and the features that they provide.

Not only does the hibernated system load up faster, the user also gets back to his previous session without much effort

History and available methods in Linux

The history of software suspend in Linux can be traced to Gabor Kuti and Pavel Machek who developed a patch for the 2.2 series known as swsusp. It was probably an abbreviation for swap suspend as the snapshot image was written to the active swap partition of the system. Gabor used to maintain these patches on his personal page. The code base for this patch became the basis for three different implementations that we have today: swsusp, suspend2 and uswsusp.

swsusp was first incorporated in the 2.5.18 kernel. It subsequently became a part of the 2.6 stable release. Later, a fork of swsusp, known as pmdisk evolved. The difference between swsusp and pmdisk was that the latter’s code was much cleaner and well structured. Moreover, while swsusp used the /proc interface, pmdisk used the /sys interface. pmdisk cleanups were eventually merged into the swsusp code base.

Among all the available methods, the one that generates the maximum excitement is suspend2 by Nigel Cunningham. It introduces some important changes in the way the snapshot image is handled and is also noticeably faster. suspend2 is currently available as a patch for 2.4 and 2.6 kernels and will hopefully be merged into the mainline kernels in future.

Also worth mentioning is uswsusp, abbreviation for userland-swsusp. It is an implementation of an interface for software suspend in the user space. All kernels starting from 2.6.17 have uswsusp merged in them. The module gives access to software suspend functionalities by exposing common file operation methods that can be used to operate on a character device. This is only useful for developers who would like to write their software suspend applications in user space and hence I won’t delve into this topic in detail here.

swsusp

How swsusp works

swsusp works by taking a snapshot of the contents of the RAM. This snapshot or suspend image is copied and then saved in an atomic operation fashion to the active swap partition. Upon rebooting, if a valid image signature is found on the active swap, the image is loaded and the snapshot transferred back to memory. This gets back the saved state to the user. The following illustration shows the sequence in simple terms:

• User requests for software suspend
• All the running processes are given the suspend signal
• The devices are frozen so that they don’t change the system state when the snapshot is taken
• The memory image is atomically copied with interrupts disabled
• Frozen devices are awakened so that the image can be written
• The image is written to swap
• Devices are suspended and the system powered off

The resume process involves just the inverse of the above steps.

Configuration and running

Configuring and running swsusp is a breeze since it is a part of the 2.6 vanilla kernel. If swsusp has not been compiled in your running kernel, you will have to enable it and recompile your kernel. It is always a good idea to compile a fresh stable version instead of tinkering with the running version because that way you always have a backup with you.

To enable swsusp, bring up the kernel configuration window:

$cd /your/linuxsourcedir
$make xconfig