The suspend2 discussion resumes [LWN.net]

One of the side discussions in the scheduler debate had to do with how the CFS scheduler broke the out-of-tree suspend2 suspend-to-disk code. Ingo Molnar, acting on the reports, found and fixed a bug in CFS. As a way of returning the favor, he then posted a review of the suspend2 code, noting that "the patch looks sane all around" and asking whether there were any plans to get suspend2 into the mainline kernel.

Perhaps Ingo wasn't listening the past few times this topic has been brought up. His question was music to suspend2 author Nigel Cunningham's ears; Nigel promptly responded with a lengthy reasons to merge suspend2 document. Among many other things, he notes that the user-space software suspend implementation (uswsusp) is still running behind suspend2 in features. It is true that little has been heard from uswsusp in recent times; there has not been a release since last November. Uptake by distributors has been slow. But that didn't stop uswsusp hacker Pavel Machek from jumping in saying "Well, current uswsusp code can do most of stuff suspend2 can do, with 20% (or so) of kernel code."

Those who followed the discussion one year ago when uswsusp was merged may remember that it triggered a debate on which functions can sensibly be moved out of the kernel to user space. Many developers thought that suspend-to-disk functionality was, perhaps, on the wrong side of that line. After this debate, the number of proposals for moving functionality out of the kernel fell significantly. People are still sensitive to the issue, though, as can be seen in this response from Linus:

This whole notion that "kernel lines of code" is somehow different is a stupid and idiotic _disease_ that is spread by microkernel people and people who have been brainwashed by them.

In a later, calmer moment he added:

This is why I don't believe in the whole kernel-line-counting thing. I'm personally 100% convinced that it's better to have ten times as many lines in the kernel, if it means that you can just forget about version skew and bad user-space interfaces etc.

This discussion should help to keep a lid on future "move kernel code to user space" projects. While there are certainly times when such moves make sense, there are also situations where putting functionality in user space just makes things harder. That said, one should not expect the recently-posted Kcli patch, intended to help move entire applications into the kernel, to get into the mainline anytime soon.

Meanwhile, what about suspend2? It is possible that the renewed discussion might provide some impetus for the merging of this longstanding development. Certainly suspend2 has a significant user community which would appreciate inclusion in the mainline. The amount of discussion has been relatively low, though. It may well be that enough systems now have working suspend-to-RAM support that the level of interest in suspend-to-disk is rather lower than it once was.

to post comments

The suspend2 discussion resumes

Posted Apr 26, 2007 1:13 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

unfortunantly for LWN this discussion is continuing hot and heavy as this week's edition goes live.

at the moment it looks like there is going to be a significant split between teh suspend-to-ram and suspend-to-disk functionality.

this discussion is probably going to generate some items for the quote of the week section next week ;-)

The suspend2 discussion resumes

Posted Apr 26, 2007 3:21 UTC (Thu) by sbishop (guest, #33061) [Link]

Speaking of quotes, this one from Linus made me chuckle:

'... so there's no need to have a "synchronization event" when ram and devices match. The RAM will *always* match whatever any particular device has done to it...'

I work for a memory manufacturer, and the group I'm in was created a few years ago because our chips used to be so bad at coming out of "self refresh", the low-power state used in suspend-to-RAM. Our VP was tired of apologizing to our customers, so he put us in charge of making sure those kinds of problems don't happen again.

Luckily for you all, our memory is much, much better now than it was back then. But Linus, "always" is a pretty strong word! ;)

The suspend2 discussion resumes

Posted Apr 26, 2007 1:13 UTC (Thu) by elanthis (guest, #6227) [Link] (13 responses)

Suspend-to-disk will still be useful even for people who have working suspend-to-RAM. Even in low power modes, batteries still run out. In cases when a computer needs to be disassembled or unplugged, suspend-to-disk can still be quite useful.

The suspend2 discussion resumes

Posted Apr 26, 2007 10:57 UTC (Thu) by NAR (subscriber, #1313) [Link] (5 responses)

Suspend-to-disk is also useful to avoid the long shutdown/startup times.

Bye,NAR

The suspend2 discussion resumes

Posted Apr 28, 2007 17:54 UTC (Sat) by xma (guest, #44981) [Link] (4 responses)

Maybe I am dumb but here, s2d has never been quicker than a full
shutdown/power up cycle. I have tried suspend2, sysfs disk, etc.

Sysfs disk is the best implementation and quicker I have found. Suspend2
is often crashing when hibernating, dunno why but since I switched for
sysfs, I never had such crashes.

The suspend2 discussion resumes

Posted Apr 28, 2007 20:14 UTC (Sat) by hingo (guest, #14792) [Link]

On Windows, suspend to disk is significantly faster to wake up from than a shutdown/boot. One factor to this are the many applications (incl some written in Java) that want to start at login and reside in system tray.

A Kubuntu on a modern laptop on the other hand boots so quickly I wouldn't even think of any suspending.

The suspend2 discussion resumes

Posted May 1, 2007 6:42 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

> s2d has never been quicker than a full shutdown/power up cycle

So, when you have 20 apps open, it is faster to shut down, reboot, log in, start the apps up again and return to exactly the spot where you've been X number of days ago (provided you can still remember)? I don't think so.

Suspend2 actually resumes very quickly (async I/O and multi-threaded decompression) and all apps are 100% responsive on resume, because Suspend2 saves the whole image of memory, unlike any other suspend to disk solution for Linux.

The suspend2 discussion resumes

Posted May 1, 2007 7:51 UTC (Tue) by xma (guest, #44981) [Link] (1 responses)

First, it is unlikely I am running 20 apps at once. The basic situation
here is quite simple: GNU Screen + GNU emacs. When in X, I am running a
common lisp image containing my window manager and the sole X app I use is
konqueror).

Thus suspending/resuming (to disk) is useless for me (plus it often does
not suspend but crashes). I only use echo mem > /sys/power/state (s2r).

Maybe I am missing something.

The suspend2 discussion resumes

Posted May 1, 2007 8:02 UTC (Tue) by bojan (subscriber, #14302) [Link]

You obviuosly have a very simple situation.

I have 6 workspaces full of apps. Rebooting and getting to where I was is a painful exercise. Suspending to RAM is good, but what when I need to travel and take my notebook with me? I don't want to rely on my battery lasting through all this. And what if it comes out while the notebook is being handled by airport security?

Suspend to disk is the right thing to do for me. I get to exactly where I was in 30 seconds or so.

The suspend2 discussion resumes

Posted Apr 27, 2007 20:20 UTC (Fri) by aegl (guest, #37581) [Link] (6 responses)

In a laptop with a flash drive (either instead of, or in addition to a normal spinning drive) suspend to "disk" could conceivably be made fast enough that suspend to ram becomes irrelevent.

The suspend2 discussion resumes

Posted Apr 28, 2007 2:51 UTC (Sat) by dlang (guest, #313) [Link] (5 responses)

I don't think that it's very likely (after all, to do a suspend-to-disk you have to copy the contents of ram to the disk, that takes time)

also, suspend-to-ram can be made so fast and cheap that something like the OLPC can go into suspend mode between keystrokes

The suspend2 discussion resumes

Posted Apr 30, 2007 14:36 UTC (Mon) by k8to (guest, #15413) [Link] (3 responses)

Perhaps, theoretically you could have some kind of low priority system goal of synchronizing memory space with a section of flash, so that when you eventually try to suspend, the vast majority of the copying has already occurred.

This would likely only be helpful on desktop/laptop systems, but I think this is where we care about such a feature anyway.

The suspend2 discussion resumes

Posted Apr 30, 2007 16:27 UTC (Mon) by aegl (guest, #37581) [Link]

There is a constraint on the number of write/erase cycles the flash can go through. Unless new designs can survive orders of magnitude more cycles than current ones, it might be a bad idea to try to keep memory and flash in sync.

Also all those extra writes to flash are going to use power, reducing battery life.

The suspend2 discussion resumes

Posted May 1, 2007 9:13 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

with suspend to ram you don't have to copy anything. the ram where the data lives is where it's being suspended to

you are also forgetting how slow flash is, it fast compared to magnetic media, but as far as memory types go it's one of the slowest available.

hardware speed

Posted May 4, 2007 21:41 UTC (Fri) by anton (subscriber, #25547) [Link]

you are also forgetting how slow flash is, it fast compared to magnetic media

The seek time of flash is fast compared to disks, but the bandwidth of flash drives is usually lower. And a well-designed suspend-to-disk should dump and restore memory as one big extent on disk, so seeks should not play a role. Therefore I would expect flash to be slower than hard disks for this application.

Just to give you some numbers: A modern disk drive has a raw bandwidth of 70MB/s, a fast USB flash stick has 30MB/s, and the fastest CompactFlash cards have 40MB/s, but most are far slower (mine is 3MB/s).

The suspend2 discussion resumes

Posted Apr 30, 2007 16:22 UTC (Mon) by aegl (guest, #37581) [Link]

I was only thinking about "close the lid" suspend ... for which the requirement is to save the state in a time that is short enough to not annoy the user ... perhaps a few seconds is okay. In a system with only a flash drive, it perhaps doesn't matter if the saving of state takes a few seconds longer as there are no drive heads to bounce when the user picks up the laptop and tosses it into their backpack.

But you make a good point about save to mem for power saving purposes when the system is idle for "long" periods like between keystrokes.

The suspend2 discussion resumes

Posted Apr 26, 2007 12:12 UTC (Thu) by ortalo (guest, #4654) [Link] (3 responses)

Hey, that reminds me: why not put the X server inside the kernel then (maybe it would solve interactive tasks scheduling issues elegantly by the way)?
Ah ah ah!

R.O. -- former anonymous KGI hacker

The suspend2 discussion resumes

Posted Apr 26, 2007 14:19 UTC (Thu) by Randakar (guest, #27808) [Link] (2 responses)

You're laughing, but I actually heard some noises about moving the drivers X uses into kernel space - in an interview with Keith Packard, of all people.

Looks like there is a good argument to be made for such a development.

The suspend2 discussion resumes

Posted Apr 26, 2007 15:45 UTC (Thu) by pjones (subscriber, #31722) [Link] (1 responses)

The whole X server? I think not. But there has been serious (and reasonable) talk of moving video mode setting and power management to the kernel. This would help simplify quite a lot of code, and not just in X.

The suspend2 discussion resumes

Posted Apr 26, 2007 16:59 UTC (Thu) by jsbarnes (guest, #4096) [Link]

In fact, it's already working to some extent on Intel hardware. Check out
the modesetting-101 branch of the DRM tree: full kernel modesetting,
video output detection and management, and a DRM based framebuffer console
(and lots of bugs & missing features :).

A bit of history

Posted May 1, 2007 6:52 UTC (Tue) by bojan (subscriber, #14302) [Link] (5 responses)

It is worth remembering that a Suspend2 discussion occured over a year ago on LKML, at which point the maintainers of uswsusp kept pointing out that all that Suspend2 can do, can be done in uswsusp. Over a year later uswsusp still cannot match what Suspend2 can do. Not to mention that you need a PhD to set it up.

A year ago major complaints were that nobody reviewed the code and that there is too much kernel code (which we now see is apparently rubbish), making Suspend2 overly complicated. Now, all that's not the case any more, but Linus still refuses to merge it. Apparently, all three suspend to disk solutions suck - but selecting the best of the three and working from there is not good. Go figure...

In the meantime, most users will still have to rely on the old swsusp, which is, shall we say, less than perfect. Sad...

A bit of history

Posted May 1, 2007 8:41 UTC (Tue) by xma (guest, #44981) [Link] (4 responses)

What does suck with s2d according to Linus exactly ?

Dunno for uwsusp but AFAIK, it works like a charm with current in-kernel
implementation and works most of the time with suspend2. Right ?

A bit of history

Posted May 1, 2007 9:10 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

Linus is arguing that the fact that S2ram and S2Disk are being treated the same is a fundamental misdesign.

for S2D you don't need to worry about freezing devices or kernel threads, and needs little, if any driver support. instead all you need to do is atomicly make a snapshot of memory and make it so that devices don't get written to (or any writes can be thrown away, say for example useing the LVM snapshot capability) userspace can then resume, do whatever it wants with the snapshot of memory (compress it, encrypt it, save it to disk, send it over the network, etc) and then do a normal shutdown.

to restart you boot any kernel , load the image into ram, and do something like a kexec to switch back to the old kernel.

performance for this is very much not critical (especially for the suspend)

for for S2Ram you also don't need to do as much as is currently being attempted. instead you just pause userspace, and power devices down in order. then to resume you power the devices back up and resume userspace scheduling.

the ultimate implementation of S2Ram is something like the OLPC, with properly selected hardware it can look seriously at doing a suspend to ram between keystrokes. to do this the performance is critical.

the current process that tries to have one routine do the job for both purposes not only fails to do either job well, but it also manages to confuse people about what the function call is supposed to do which makes it almost impossible for developers to do it well

after a lot of yelling and screaming he has everyone convinced that the two types of suspend need to be seperated (in fact, to avoid confusion S2D is being called 'hibernation' instead of 'suspend')

what happens next is going to be interesting.

one possible approach is to implement what linus is proposing for hibernate, which includes a new API and new userspace tools. if this happens it may end up that the disk snapshotting will literally use the LVM tools. This would require people who want to do hibernation to prepare for it by configuring their drives to support snapshots, but avoids a HUGE amount of hibernation specific code in drivers.

the suspend to ram will need driver support, but since the driver routines will not be nearly as complicated (and for most drivers most of the routines are noops) it should be much easier to get the needed support in place.

one thing I would like to see someone try for the hibernate situation is to take a look at the virtulization work that's being done, especially the work to migrate processes from one system to another. I think the ulimate hibernation would be to grab each set of processes that are entangled with each other (via unix sockets, shared memory, or other IPC mechanisms) and treat each one as seperate entity, storing it to disk. then it would even be possible to 'wake up' on a new kernel that then has the processes continue where they left off.

A bit of history

Posted May 1, 2007 21:50 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

Thanks dlang - nice summary of that LKML thread.

One thing I noticed in the thread is that if one wants to write the full image of memory, all processes must get frozen to prevent memory modification, according to designer of Suspend2, Nigel. This is something Linus didn't take into account, I think.

Also, these days many people set their systems up to suspend to disk, but then enter suspend to RAM after the image has been written to disk. This approach guarantees minimum resume time as long as the system has uninterrupted power and also guarantees resume if the power is lost. With current design, I think ACPI is instructed to set the suspend state after writing the image, given that everything is already suspened. With the new design, suspend round would have to follow snapshot, leaving the system in a slightly different state than when the snapshot was taken.

In any event, I have no idea why users have to suffer inferior solutions while the new stuff is being developed. I'm guessing because Linus thinks that suspending to disk as a concept is wrong or something and is personally not interested in it. In the meantime, users find it indispensable.

Suspend2 should have been merged long, long time ago - it's just that the subsystem maintainer is bent on not having it. Everybody had to endure his "too many lines of kernel code" arguments, which we now know are nonsense. Kernel is always supposed to get more sophisticated - this is how it's been for a long time now - and it's not about to change.

Sure, like any piece of software, Suspend2 has problems, but Nigel has always been extremely responsive. And, at the end if the day, neither swsusp nor uswsusp can do many things that Suspend2 can. So, while we're waiting for the next technology to be written, we should have the best.

A bit of history

Posted May 1, 2007 22:14 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

Quote:

Linus is assuming that you can get away with writing less then the full contents of ram (current suspend stuff does this as well, it tries to make the image smaller if possible, in part by throwing away cached pages)

the amount of free memory needed could be surprisingly small. one approach is to mark all of the process and kernel memory COW and let the system make room for it by throwing away caches as needed.

the existing strategies seem to be in the 'I have a hammer (freezing) so everything looks like a nail' catagory. one big benefit of the discussion is that people are seriously looking at other options.

A bit of history

Posted May 1, 2007 23:07 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Linus is assuming that you can get away with writing less then the full contents of ram

Yes, I noticed. However, writing a full image of memory and resuming that leaves the system in a much more responsive state. Talking from personal experience here. Actually, on my old notebook (4200 rpm disk), writing full image of memory with Suspend2 and resuming that is faster than writing/resuming half the memory with swsusp, due to compression. On resume, the system is just as it was before with Suspend2. With swsusp, I have to wait for apps to page stuff in. Annoying.

I know Linus personally doesn't care, because he never suspends to disk, so he may be inclined to go with a simpler solution because it's a cleaner design. From my user perspective, this is a step back in functionality.