Merging swsusp2

Once upon a time, the 2.6 kernel had three software suspend implementations - two of which were in the mainline - but none which were seen to work all that well. Since then, the two mainline implementations have been merged, and the out-of-tree swsusp2 implementation has come a long way. Still, two implementations of a low-level core function seems like too many, so there is interest in bringing them together in the mainline. Swsusp2 developer Nigel Cunningham has made a new effort in that direction by posting a set of 51 patches which merge swsusp2 into the 2.6 kernel.

There is a great deal of code in these patches. Some of the more interesting pieces include:

• A set of new exported symbols; these include fundamental things like sys_ioctl(), avenrun, and a number of low-level swap functions. These exports were poorly received; there is currently a great interest in reducing the number of symbols exported to modules. A patch which, instead, exports fundamental interfaces is bound to encounter some resistance.

  The swsusp2 code wants these symbols exported because the entire suspend mechanism can be built as a module and loaded only when the system is to be suspended. This can be a nice feature; swsusp2 is a lot of code, and it is all excess baggage anytime the system is actually being used. The costs of making swsusp2 modular may prove too high for that feature to be accepted into the mainline, however.

• A change to the workqueue API allowing the creator of a workqueue to specify whether that queue should be left running during the suspend process. Some workqueues perform tasks which are needed during the image writeout process, and thus cannot be stopped prematurely.

• A replacement refrigerator, the code charged with putting all processes on hold so that the system is in a quiet state before suspending. The intrusive macros which characterized the swsusp2 refrigerator some time ago are gone. The new version relies upon a PF_SYNCTHREAD task flag to keep processes (temporarily) from being frozen while they are doing some work involved with writing data to disk.

• A complicated I/O infrastructure for writing the suspend image to disk. The new I/O code is said to be much faster, and it supports features like image compression, writing to swap files or LVM devices, etc. Future plans call for more esoteric features, such as suspending across a network. These features may be nice, but it has been pointed out that the swsusp2 I/O code alone outweighs the entire mainline software suspend code by a significant amount.

• Various types of "nice displays" when a suspend or resume is in progress. These displays include progress bars, splash screens, and more.

Nigel offers a number of reasons for merging swsusp2. It is claimed to be much faster as a result of the use of asynchronous I/O, readahead on resume, and (for systems with slow drives) image compression. It is far more configurable; users can select the sort of display they like, image compression and/or encryption, etc. Suspending to swap files, LVM devices, and more is supported. And so on. There is little disagreement that swsusp2 offers some nice features, but there is some concern over how Nigel is trying to proceed:

The kernel developers are increasingly resistant to wholesale merging of large blocks of code - especially when that code duplicates functionality already found in the kernel. They would rather see a series of incremental patches, each of which takes a small, useful step in the right direction. Nigel does not want to do that; swsusp2 is vastly different, internally, than the mainline suspend code, and evolving one into the other looks like a long, painful, and pointless job. He may have to do that work, however, before any of the swsusp2 code can be merged.

A bigger obstacle, however, may be the fact that, while swsusp2 was being developed, the mainline software suspend code was progressing too. Your editor is able to reliably suspend to memory and disk with a vanilla 2.6.9 kernel. SUSE enables software suspend and calls it a feature in its 9.2 release. Since the in-kernel suspend code seems to actually work, enthusiasm for replacing it with a larger, more complex version is not as high as it might otherwise have been. The ultimate fate of swsusp2 may yet be to contribute its best improvements to the mainline, but to never be merged in its entirety..

Index entries for this article
Kernel	Software suspend

---

to post comments

swsusp2 and smp

Posted Dec 2, 2004 7:56 UTC (Thu) by Duncan (guest, #6647) [Link]

I'm still waiting for software suspend that
actually works on SMP (and
amd64 smp at that). I've been told swsusp2 does, but haven't wished to go
adding a patch set like that to my otherwise basically vanilla kernel.
Thus, I'm really interested in seeing swsusp2 merged.

Presently, I can disable ACPI and use APM hardware suspend (to ram), and
that's what I've been doing lately. The problem there is things like ntpd
which don't know they are suspended. I end up having to stop ntpd, then
restart ntp-client and ntpd after awakening. It'd sure be nice to have
all that handled automatically, with acpi enabled.

The other possibility, of course, is that of using the evolving CPU
hotplug technology to handle both suspend, and CPU speed throttling (which
also doesn't work on smp) as well. The idea, once CPU hotplugging is
sufficiently mature, would be to use its process migration features to
turn off one CPU at a time until only the primary CPU remains, at which
point the system could treat it like a single CPU system and trottle or
suspend it accordingly. Of course, in addition to the other complexities
of such a solution, consider NUMA architectures and the entirely possible
scenario where the memory accessible to a single CPU won't hold the entire
running system. We then end up having to swap what won't fit to
disk, /then/ do the throttling or suspending of what remains. If it's not
handled carefully, that's begging for a swap storm and some unfortunately
long time-to-single-cpu while headed to throttling mode or suspend. For
suspend that might be acceptable, but if it takes 30 seconds to turn on or
off the second CPU on the way to what's supposed to be transparent
throttling mode, it's not going to be acceptable.

Anyway, mature CPU hotplugging seems to be some time off in the first
place, and beyond that it'd have to be adopted for this, so swsusp2 would
appear to be a quicker solution. I'd love to have it in the kernel to
play with, particularly if it DOES handle multiple CPUs.

BTW, anyone know how multi-core CPUs will be handled in this regard? One
would /think/ the hardware at least would be able to handle that without
the race conditions in the multi-socket solution. Will the kernel and
necessary userspace handle it as well, or will it see it as two physically
separate CPUs and refuse to handle them with "conventional" throttling and
suspend mechanisms?

Duncan

Merging swsusp2

Posted Dec 9, 2004 20:00 UTC (Thu) by danielos (guest, #6053) [Link]

"""
Your editor is able to reliably suspend to memory and disk with a vanilla 2.6.9 kernel.
"""

Reliably? no problem with clock? usb?

To me it seems almost working, but not a feature.

(lalala, when I'll sm*ke a 20 sig less per month I'll subscribe ... and I'm going to do it... sure: first redution was for pay hosting)

Merging swsusp2

Posted Dec 10, 2004 22:18 UTC (Fri) by NCunningham (guest, #6457) [Link]

I'm working toward addressing many of the issues raised in this first submission of the code.

Some of the comments will be rejected though.

Regards,

Nigel