LWN: Comments on "Kernel Summit 2006: Software suspend"

Kernel Summit 2006: Software suspend

quintesse — Fri, 28 Jul 2006 07:47:44 +0000

"if people had a choice between suspend to disk vs suspend to ram most would choose suspend to ram"

Don't know about most, I for one never use it. I don't want to have to deal with the fact that the battery on my laptop runs out before I'm able to connect it again.

So closing the lid does nothing on my laptop while a quick press of the power button will suspend to disk. Just as easy and whithout having to worry about anything.

And all of it thanks to Nigel's swsusp2. Persoannly I don't care about which one is supposed to be "better", for me swsusp2 is the only one that actually works!

Kernel Summit 2006: Software suspend

huaz — Thu, 27 Jul 2006 20:12:10 +0000

: That said, there is still little interest in bringing the suspend2 code into the kernel.

..by the current maintainers who are afraid to lose the title.

: The quality of this code was criticized

..by the current maintainers who don't have a working implementation. It's ridiculous. So the current in-kernel swsusp has a better quality but just doesn't work on as many systems as reliably.

Go figure.

: In any case, the real problem with software suspend is not the core code, which is highly similar between all of the implementations. It lies, instead, with device support.

Yeah, blame the drivers. How come suspend2 is more successful if drivers are the same? One has to wonder.

Kernel Summit 2006: Software suspend

huaz — Thu, 27 Jul 2006 20:08:02 +0000

: Suspend to RAM works perfectly on my laptop (Debian Sid on Ibook). I think
: that is what matters for most users.. or at least if people had a choice
: between suspend to disk vs suspend to ram most would choose suspend to ram.

Please, speak only for yourself.

I never use suspend-to-ram, even on Windows.

Kernel Summit 2006: Software suspend

rvfh — Thu, 27 Jul 2006 14:19:56 +0000

> nobody needs again 2 in kernel solutions.

swsusp and uswsusp? Isn't that TWO broken in-kernel solutions?

I don't care that swsusp and suspend2 SHOULD fail on the same machines: they don't. Suspend2 is successful where swsusp is NOT. Example: my wife's laptop. And that's pure FACT, no opinion.

And I also don't care that uswsusp COULD do the same as Suspend2, because for now it does not. Suspend2 is FASTER then Windows and just as good.

As a last note, I remark than Andrew Morton himself does not like the idea of user-land suspend. So what are they waiting for? A few changes to the patches? Let them come along, and let's have Suspend2 in the kernel. QUICK! We're six YEARS late!

Kernel Summit 2006: Software suspend

jneves — Tue, 25 Jul 2006 10:27:52 +0000

In my case the answer is no. I choose suspend to disk. It allows me to become productive less than 30s after powering up my laptop with a useful system state. With suspend2, I've done "uptimes" of over 30 days with my laptop without a full reset. It's great to turn the power on and be able to start working almost immediately (instead of going for a cup of coffee - or in my case, an apple).

Kernel Summit 2006: Software suspend

riteshsarraf — Fri, 21 Jul 2006 15:02:36 +0000

I had the understanding that Free/Open Software was a platform where one
could try innovative work because you had all the freedom.
But that doesn't seem to be the case anymore with the comments most
people give here.

The decisions, these days, about what should and shouldn't be included in
the kernel seems to be driven more by the corporations backing them.

Look at Software Suspend 2. It has features, which AFAIK, no other OS
has. Atleast one, cancelling a suspend in between. Another is speed.

And Software Suspend 2, interestingly, is not even in the -mm tree.

If people still claim that Linux is Free Software just not in terms of
the legal aspect, I believe you should fork a development branch to
incorporate these innovative new features and work on them.

I don't think "backward compatibility" is going to allow innovation that
easy. But yes, being compatible with the kernel is very important, both
for the developer and the user.
I think a development branch is the best thing to do at the moment.

Kernel Summit 2006: Software suspend

drag — Thu, 20 Jul 2006 09:16:45 +0000

Suspend to RAM works perfectly on my laptop (Debian Sid on Ibook). I think that is what matters for most users.. or at least if people had a choice between suspend to disk vs suspend to ram most would choose suspend to ram.

I mean it's pretty nice. I just close the lid, stick it in the bag and walk around with it. I open it up nm-applet notices that it lost the connection and then finds a new one. All of it is pretty hands off for me and it's all very quick.

Although suspend to disk should be easier for devices with not-so-hot acpi support, correct?

On my desktop suspend to ram ALMOST works, which would be very kick-ass. I can get it to suspend to ram and even save the video state... When it starts back up X and everything is running fine... except that the SATA controller proceeds to start to puke immediately. I figure that when libata stuff gets power management support this would help out a lot, maybe?

Kernel Summit 2006: Software suspend

christian.convey — Wed, 19 Jul 2006 21:21:45 +0000

No, I'm *not* suggesting that Nigel does this work himself necessarily. The specific plan I gave was just an example of incremental progress. I have no idea whether or not that particular plan would be a good one. And even if it is, I'm not saying that Nigel needs to do the work himself - just that he needs to ensure that the kernel tree evolves in a way compatible with his plan to get all of suspend2 into it.

Don't miss my main point: breaking a large change into smaller, more digestable changes is sometimes the most expedience way to achieve the results of the large change. That was my only point.

Kernel Summit 2006: Software suspend

bojan — Wed, 19 Jul 2006 20:02:56 +0000

> Second, ensure the drivers are up to snuff.

You are kidding, right? Nigel is to do *all* driver fixing by himself?

Obviously, Nigel would have to have intimate knowledge of every single broken driver out there and then have the time to actually fix it. In fact, Nigel did fix quite a few, but asking to do the lot is a bit much.

AFAIK, current suspend subsystem maintainers fix drivers only when they happen to have a good handle on the driver in question. Otherwise, they defer to that subsystem maintainer.

Kernel Summit 2006: Software suspend

christian.convey — Wed, 19 Jul 2006 16:55:28 +0000

I suggest looking for a sequence of patches that would be made to the tree, that would ultimately result in the code looking exactly as you want.

For example, first try to submit patches that provide the front-end that you want, but that works on swsup. Second, ensure the drivers are up to snuff. Finally, now that the differences between the in-tree code and your ideal are small, provide patches that finish the job.

The key here is that you ensure every patch is desirable to the kernel maintainers even if they're not committed to making suspend2 be tge standard. Just a thought. I'm not a kernel maintainer, but I do believe this general approach works well in the research field.

Kernel Summit 2006: Software suspend

lamikr — Wed, 19 Jul 2006 01:12:19 +0000

How about adding suspend2 to kernel now as it is the best thing
currently available. And if there really makes sense to move some
parts of it to userspace, start the progress from there a little by little instead of waiting until swusp gets those features in some years from this day...

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 23:11:19 +0000

> the hole suspend2 base is much to huge to get gobbed on once. even ubuntu cares about driver fixes these days.

Split Suspend2 patches were posted to LKML recently. Sure, there were real technical complaints from people that actually reviewed the patches - all of these are being addressed as I understand, with some of the stuff already done.

Unfortunately, some other developers have chosen to repeat myths about Suspend2 instead of actually reviewing the code. Like: don't have userui in kernel - it hasn't been there for a while. Or: can you remove crytpo/compression - well, ignore two files from the patch etc. I guess Nigel is right when he says that the initial invasive nature of Suspend2 patches is still lingering in the air, although it hasn't been true for a while now.

> make out of swsusp and suspend2 a great in tree suspend3

Well, that would be a great outcome. However, it seems that it isn't going to happen. Current suspend subsystem maintainer wants to keep the in-kernel code (mostly) the way it is to reduce complexity. I was under the impression that Linux kernel has gone way past that point (i.e. of being really simple) with the introduction of many advanced features, but then again I don't know the code of it, so I'm probably wrong.

Kernel Summit 2006: Software suspend

maks — Tue, 18 Jul 2006 22:32:58 +0000

> Given the above, I don't know what the way ahead is from here, but if
> someone wants to suggest one (and it doesn't kill me in the process :>),
> I'm willing to listen.

the hole suspend2 base is much to huge to get gobbed on once. even ubuntu cares about driver fixes these days.

concerning pavel i remember him merging 2 bad in kernel solutions to one,
that was already a very good start.

you have been last year in locked in one room. the advise gregkh and others have most probably given is incremental improvements on the in kernel solution. make out of swsusp and suspend2 a great in tree suspend3 :)

Kernel Summit 2006: Software suspend

NCunningham — Tue, 18 Jul 2006 21:57:55 +0000

Hi Dave.

My primary concern is having it 'just work' too. That's why I put the
time in to suspend2.

Obviously I got the order wrong as far as "getting it working well"
and "getting it merged goes". Do you have suggestions for a way forward?

Nigel

Kernel Summit 2006: Software suspend

NCunningham — Tue, 18 Jul 2006 21:53:06 +0000

AFAIK, Suspend2 works on any machine swsusp works on - it now uses the
same lowlevel code, and they both use cpu hotplugging, so if one is
broken, the other should be too.

Kernel Summit 2006: Software suspend

NCunningham — Tue, 18 Jul 2006 21:51:04 +0000

Yes, Rafael's fixes have helped.

It's not so much that I like my 'out of tree playfield', as that dealing
with Pavel is a pain. For some reason, we just don't get along, and
submitting patches to him is like banging your head against a brick wall.
Noone is going to want to try that for long.

But he had the foresight and understood the process well enough to fork
swsusp and get the fork merged when it was still beta software, whereas I
ignorantly thought it was best to get it working properly and well before
merging.

Given the above, I don't know what the way ahead is from here, but if
someone wants to suggest one (and it doesn't kill me in the process :>),
I'm willing to listen.

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 20:35:35 +0000

> Frankly, I couldn't care less about the 'features'.

Yeah, I noticed many kernel folks share the same view. From my, user perspective, many of those features are very important - especially speed (you kind of want your disk to stop spinning before you slam the laptop in the bag :-). Other users on Suspend2 list report that things like support for swapfiles and regular files is what they find extremely useful in their situations. And then there is responsiveness of the system when it resumes - it's simply essential.

> They're all cute hacks, but lets at least get the functionality there before we start polishing it ?

AFAIK (and this is according to Pavel on LKML), swsusp is not going to be enhanced because it's more or less deprecated in favour of uswsusp. Which is an attempt to build all those Suspend2 features in userspace. Which functionality are you referring to above? Is it the drivers or something more fundamental (e.g. recent patches from Linus to introduce another stage in suspend cycle of the kernel)?

Kernel Summit 2006: Software suspend

davej — Tue, 18 Jul 2006 20:18:23 +0000

Frankly, I couldn't care less about the 'features'. Looking at Fedora bugzilla, I have lots of bugs from people wanting it to _JUST WORK_.
I've never seen a single bug report "I want it to look pretty whilst its doing its thing", or "I wish it would write to a swapfile" or "I want to cancel it during a suspend". They're all cute hacks, but lets at least get the functionality there before we start polishing it ?

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 20:14:56 +0000

> swsusp works fine here (mem, disk) on x60 once you set an bios sata option to compatible.

Apparently, this is the case with Suspend2 as well on this hardware:

http://www.gnugrass.com/personal/x60.html

On my dual core hardware, I can get both working, but only "sort of" for now. Both still have problems with (surprise) various drivers.

Sure, sometimes one solution will work on some hardware and won't on another. But generally speaking, as of recent, both have similar success rates. Which, of course, is no accident - they rely on similar stuff in the kernel to do things.

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 20:09:47 +0000

> The obvious answer is "Report bugs".

Which is going to be of great help when that stop is about to come up ;-)

Seriously - of course, you're right. But it's not like driver writers cannot find out which modules have problems. In fact, all of these have been listed in /etc/hibernate/blacklisted-modules for a few years now. And yes, Bernard's hibernate scripts work with both Suspend2 and swsusp, so it's not a Suspend2 only thing.

> "swsusp sucks, it doesn't work, but suspend2 does".

Look, I'll admit that at times I used to say things along those lines when I got annoyed by certain people's arguments. But, I'm not saying that in this thread, because I don't want (any more) flame wars on this topic.

What I'm saying is that Suspend2 can do things that swsusp cannot. Or are you claiming that those two have equivalent functionality? If that is true, why is then uswsusp being built to cover all of the ground that Suspend2 already covers?

Kernel Summit 2006: Software suspend

davej — Tue, 18 Jul 2006 19:26:18 +0000

The obvious answer is "Report bugs".

"I can't suspend/resume unless I load module.ko first" is more likely to get things fixed than..

"swsusp sucks, it doesn't work, but suspend2 does".

Kernel Summit 2006: Software suspend

cventers — Tue, 18 Jul 2006 13:13:52 +0000

Well then perhaps I've understood the scope of your statement. If I did,
I apologize.

What I mean to say is that the kernel developers certainly shouldn't
endorse module blacklisting. But users do many "dirty" things to work
around the problems in the software they use, and as long as those bugs
get reported, it's probably not too bad that the users do this. (Well,
they might scream at the kernel guys more often about their bugs if there
were no way around them, but what an imperfect world we find ourselves
in :P)

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 12:55:23 +0000

> Do you think that covering them up now is a good way to keep attention on getting them fixed?

No, I don't.

But what other choice do I have when I have to suspend my laptop on the train to work and my stop is about to come up? Sure, I can run Windows or Mac OS X, but I'd rather not.

Kernel Summit 2006: Software suspend

cventers — Tue, 18 Jul 2006 12:47:58 +0000

> Blacklisting modules is a necessity until the drivers get fixed.
> Otherwise, many machines would not be able to suspend or resume.

I sympathize with you, but I think this is a bit shortsighted. Papering
over problems has never been a comfortable thing for Linux kernel
developers (though I hesitate to say that our history is free from it).

Consider the fact that some of these driver bugs /have/ been around for
as long as they have. Do you think that covering them up now is a good
way to keep attention on getting them fixed?

Kernel Summit 2006: Software suspend

maks — Tue, 18 Jul 2006 11:47:41 +0000

> So does swsusp - it's mostly a driver issue. As I can verify on my dual core laptop.

swsusp works fine here (mem, disk) on x60 once you set an bios sata option to compatible.

The driver issues are the real, good to see work on bluetooth, firewire and so on..

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 11:40:24 +0000

> <snipp unrelated talk about other os>

Always good to keep head in the sand ;-)

> afaik suspend2 routinely fails on dualcore laptops

So does swsusp - it's mostly a driver issue. As I can verify on my dual core laptop.

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 11:37:35 +0000

> One thing that should be added is that part of the reason that swsup2 works well, at least as suspected by some KS attendees, is that it has a huge list of modules to unload before suspend, so that any driver bugs are hidden.

That certainly isn't true any more. It is true that Suspend2 used to carry some driver fixes a while back, which are now merged into mainline, AFAIK. Suspend2 and swsusp use more or less the same machinery to do things. So, as both Pavel and Nigel point out, if one solution fails, the other one is likely to fail too.

What makes Suspend2 better these days is what I mentioned in my first post:

- requires little setup
- looks pretty
- is very fast to suspend and resume
- leaves the machine in responsive state
- can suspend to swap partitions, swap and regular files or combo thereof

BTW, all of these features (minus the "little setup") will eventually pop up in uswsusp. So, it's not like the are useless.

Driver issues are a completely different problem - a shared problem between all suspend solutions. Blacklisting modules is a necessity until the drivers get fixed. Otherwise, many machines would not be able to suspend or resume.

Kernel Summit 2006: Software suspend

arjan — Tue, 18 Jul 2006 11:04:03 +0000

One thing that should be added is that part of the reason that swsup2 works well, at least as suspected by some KS attendees, is that it has a huge list of modules to unload before suspend, so that any driver bugs are hidden.

While this gives an immediate short term benefit (the user suspends), there is a big long time problem with this: the bugs in the drivers do not get fixed!

There seemed to be general consensus at the KS that such blacklists of modules are bad (in addition to "it means they don't get fixed" reason, there is also the "what if it's build into your kernel" reason). The swsusp2 blacklist might well be one of the key reasons why swsusp2 works where swsusp doesn't. If that's the case... we need to fix the drivers urgently (not to diss swsusp2, but apparently there are still bad bugs left that effect everyone, even potentially swsusp2 users)

Kernel Summit 2006: Software suspend

maks — Tue, 18 Jul 2006 10:54:45 +0000

> I think that's not fair. The in-tree solution doesn't offer many capabilities Suspend2 does.

not unfair - mismanagment needs to be pointed out. It is the workflow of the Linux kernel. Prepare incremental patches that add/fix current implementation.

> What's missing from the in-tree solution is speed, versitility and user friendliness. And that's what Suspend2 is mostly about. Actually, that's what uswsusp is about too, minus the "no setup" bit.

latest gnome has an nice powermanagment frontend for swsusp and no the suspend2 struggles are mostly unrelated to the frontend it uses (unrevied code mass).
swsusp is fast enough for me and works on smp. afaik suspend2 routinely fails on dualcore laptops. swsusp is good, improve it.
nobody needs again 2 in kernel solutions.

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 10:27:26 +0000

> It's a pain that you like your out of tree playfield instead of fixing the in tree solution.

I think that's not fair. The in-tree solution doesn't offer many capabilities Suspend2 does. And every time some new feature is proposed, it's always "let's do the basics first" or "kernel is the wrong place to do it". Well, basics are mostly fine (there are bugs, sure, but which subsystem in the kernel doesn't have them?). And whether kernel is the right place to do it or not, only time will tell. How are other OSes that don't have suspend/resume problem (e.g. Windows, OSX) doing this, anyway?

What's missing from the in-tree solution is speed, versitility and user friendliness. And that's what Suspend2 is mostly about. Actually, that's what uswsusp is about too, minus the "no setup" bit.

Driver support is a problem shared between all suspend solutions. It was actually Nigel that fixed many driver issues during the course of supporting Suspend2 users.

Kernel Summit 2006: Software suspend

maks — Tue, 18 Jul 2006 09:17:23 +0000

swsusp got much better since Rafael fixes. Nigel you never posted incremental fixes to swsusp. It's a pain that you like your out of tree playfield instead of fixing the in tree solution.

current suspend grumble is sata (ahci for example) support. Most of the real trouble lies in the drivers and it's not a solution to let every distro fix it on their own.

Kernel Summit 2006: Software suspend

NCunningham — Tue, 18 Jul 2006 08:38:39 +0000

> The quality of this code was criticized

It would be really helpful to me if I could be provided with more detail
as to what the criticisms are. I'm more than willing to make
improvements, but I need to know what the problems before I can
do that.

> Nigel has not been particularly effective in his dealings with
> the rest of the kernel development community.

From my perspective, there have been two problems. The first is that it
earlier iterations of Suspend2, I tried some ways of improving
reliability that made the code more invasive and was an early adopter of
modifications that have since been merged. Since that time, those changes
have been merged and/or dropped, so the code is now not very invasive at
all. Nevertheless, the reputation remains. The second problem has been my
relationship with Pavel, which just hasn't worked because he's hell-bent
on a different path. I try to be gracious and forgiving, but I'm not so
stupid as to know when there's no hope of dealing with someone. On the
whole, though, I think I have good relations with the rest of the kernel
community. I'm more than willing to listen to feedback, and everything
sensible that gets asked of me does get done. If I have a third problem,
it would be that I'm not getting things done as fast as might be liked,
but I am trying.

Kernel Summit 2006: Software suspend

bojan — Tue, 18 Jul 2006 08:21:18 +0000

> Additionally, he [Pavel] claimed, suspend-to-RAM works on most machines

Unfortunately, not true on both of my laptops.

> It was pointed out that the suspend2 patches have a lot of happy users.

ACK.

> One is that suspend2 is generally the last resort

If you want a suspend to disk solution that:

- requires little setup
- looks pretty
- is very fast to suspend and resume
- leaves the machine in responsive state
- can suspend to swap partitions, swap and regular files or combo thereof

Suspend2 really is "last resort". Rafael says that uswsusp will get there (minus the "little setup" bit), so that's good news. However, at the moment, Suspend2 is the *only* solution that provides all of the above. It's a shame Suspend2 isn't in the mainline, especially given the fact that it doesn't remove swsusp nor uswsusp and can be compiled in/out easily.

> Nigel has not been particularly effective in his dealings with the rest of the kernel development community

Nigel has been working hard to meet the demands of other developers. /sys support is already in. The code of Suspend2 shares more of swsusp code these days etc. And, let's not forget, Nigel is still supporting all of the Suspend2 users - he sure isn't sitting idle.

To me, it does seem that some other developers repeatedly come up with requests that are based on misconceptions (e.g. that Suspend2 does user interface inside the kernel or that cryto/compression cannot be easily removed from the rest of the code). Sure, there are still some real technical complaints before Suspend2 can be merged, but I'm sure Nigel and others will eventually address those.