Kernel Summit: Software suspend
| This article is part of LWN's 2004 Kernel Summit coverage. |
Pat claimed that the existing software suspend code works on most systems. In particular, it works on all systems he has access to, so it is very hard to try to address the remaining issues. Linus asked how many people in the room were actually using the software suspend code; only a few hands were raised. He noted that there was rather too much complaining about software suspend going on, and not enough people actually working with it.
Many of the remaining problems are in device drivers. Suspend support has to be added to drivers explicitly, and, thereafter, it tends not to see much testing. So suspend support in drivers varies from nonexistent to present but unreliable. It was noted that the driver interface needs some work; the values passed to drivers are not consistent, and some drivers need more information. In particular, some drivers need to know whether the kernel is truly being shut down, or whether a different kernel will be booted; the necessary device preparation differs in the two cases. There was talk of (eventually) changing the driver API to add that information, or perhaps just adding a global variable to hold the "system intent." The global variable is seen by some as an ugly, short-term hack, but other developers fear it would never go away once it is introduced.
Software suspend is only useful if the system can, later, be restored. The current restore code is seen as being somewhat fragile; if the system's hardware is changed while things are down, they may not come back up properly. The proper approach, it would seem, is to use the hotplug system to "hot remove" all devices at suspend time, and treat everything on the system as new once it comes back up.
Some developers do not like the process of booting a Linux kernel which proceeds to overwrite itself with the system image made at suspend time. Perhaps, it was suggested, it would be better to restore directly from a minimal boot loader. That is not likely to happen, however. There is a fair amount of complicated setup which can be required before the system image can be retrieved; software RAID setup is one example. There are also, it would seem, patent issues with restoring directly from a special-purpose boot-time loader.
Nigel Cunningham's swsusp2 code was mentioned. Nigel, unfortunately, was unable to attend the summit to present his view of things. The discussion centered on the large and intrusive nature of the swsusp2 patch. What swsusp2 really needs is somebody to break it down into a series of relatively small patches, each of which can be considered on its own merits. Once that is done, some parts of swsusp2, at least, may make it into the mainline.
The discussion of future tasks was mostly taken up by details. The process of "refrigerating" processes needs to be split so that user processes are stopped before kernel processes. Once user processes are stopped, it should be possible to write their pages directly to disk, rather than copying them into a big in-memory image first. Should, it was asked, user pages be flushed out separately to backing store, or just written all together to the suspend image? The latter case is quite a bit quicker, as it turns out, both before and after the system is suspended. Writing one big, contiguous image is faster than writing many smaller chunks spread out over the disk, and it is faster to get those pages back into memory at resume time, rather than forcing them to be read individually via page faults.
Suspend to RAM was discussed briefly; there is, it seems, a resurgence of interest in this area.
One of the remaining difficult issues is restoring video state. Much of this discussion was deferred until the video drivers session later in the afternoon, however.