Pat Mochel, who has been absent from the kernel development community for
much of the last year, made a reappearance to discuss the future of
software suspend in Linux. He started by apologizing to Pavel Machek for
having forked the swsusp code a year ago. Pat has just posted a set of
patches merging his fork ("pmdisk") back into the swsusp base, so that
there will be, once again, a single software suspend implementation in the
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
>> Next: Kobjects and sysfs.
to post comments)