Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 11:37 UTC (Tue) by bojan (subscriber, #14302)
In reply to: Kernel Summit 2006: Software suspend by arjan
Parent article: Kernel Summit 2006: Software suspend

> 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.

to post comments

Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 12:47 UTC (Tue) by cventers (guest, #31465) [Link] (7 responses)

> 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

Posted Jul 18, 2006 12:55 UTC (Tue) by bojan (subscriber, #14302) [Link] (6 responses)

> 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

Posted Jul 18, 2006 13:13 UTC (Tue) by cventers (guest, #31465) [Link]

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

Posted Jul 18, 2006 19:26 UTC (Tue) by davej (subscriber, #354) [Link] (4 responses)

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

Posted Jul 18, 2006 20:09 UTC (Tue) by bojan (subscriber, #14302) [Link] (3 responses)

> 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

Posted Jul 18, 2006 20:18 UTC (Tue) by davej (subscriber, #354) [Link] (2 responses)

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

Posted Jul 18, 2006 20:35 UTC (Tue) by bojan (subscriber, #14302) [Link]

> 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

Posted Jul 18, 2006 21:57 UTC (Tue) by NCunningham (guest, #6457) [Link]

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