| |||||||||||||
Kernel Summit 2006: Software suspend
What people really wanted to talk about, however, is the user-space suspend-to-disk interface. According to Pavel, the in-kernel suspend implementation is deprecated, and will eventually be removed in favor of the user-space version. This approach makes it easier to add features like encryption and compression, and a nicer user interface as well. A fair number of kernel developers are, however, unconvinced that the user-space approach makes sense. Encryption and compression can be done within the kernel, using the infrastructure which already exists there. The suspend2 patches by Nigel Cunningham show that a nice interface can be implemented in user space, even though few seem to think that suspend2 is the right way to do it. In general, what the kernel developers - and their long-suffering users - would like to see is a suspend implementation that simply works; progress bars are something which can be worried about later on. The current user-space work, says Andrew Morton, is "madness." It was pointed out that the suspend2 patches have a lot of happy users. This implementation is said to be more robust. A couple of reasons for this perception were floated. One is that suspend2 is generally the last resort of people who cannot get the in-kernel software suspend to work; those who have success with suspend2 will, naturally, see it as being better. Ted Ts'o noted that suspend2 has an active user and developer community which provides a high level of support to people trying to make it work. Users of in-kernel suspend, instead, tend to be on their own. The existence of this support system makes a huge difference for people trying to set up a tricky feature like suspend-to-disk. That said, there is still little interest in bringing the suspend2 code into the kernel. The quality of this code was criticized - and Nigel was not there to defend it. Whether or not those criticisms are valid, it is true that the suspend2 patches are huge, and that Nigel has not been particularly effective in his dealings with the rest of the kernel development community. Getting any sizeable portion of suspend2 merged seems like an unlikely prospect. 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. In many cases, the required fixes are said to be relatively straightforward, but people are not doing that work. Until that changes, software suspend is likely to remain a tricky affair.
(Log in to post comments)
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 8:21 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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
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.
Kernel Summit 2006: Software suspend Posted Jul 20, 2006 9:16 UTC (Thu) by drag (subscriber, #31333) [Link] 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 Posted Jul 25, 2006 10:27 UTC (Tue) by jneves (guest, #2859) [Link] 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 Posted Jul 27, 2006 20:08 UTC (Thu) by huaz (guest, #10168) [Link] : 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 Posted Jul 28, 2006 7:47 UTC (Fri) by quintesse (subscriber, #14569) [Link] "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 Posted Jul 18, 2006 8:38 UTC (Tue) by NCunningham (guest, #6457) [Link] > The quality of this code was criticized
It would be really helpful to me if I could be provided with more detail
> Nigel has not been particularly effective in his dealings with
From my perspective, there have been two problems. The first is that it
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 9:17 UTC (Tue) by maks (subscriber, #32426) [Link] 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 Posted Jul 18, 2006 10:27 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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 Posted Jul 18, 2006 10:54 UTC (Tue) by maks (subscriber, #32426) [Link] > 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.
<snipp unrelated talk about other os>
> 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).
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 11:40 UTC (Tue) by bojan (subscriber, #14302) [Link] > <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 Posted Jul 18, 2006 11:47 UTC (Tue) by maks (subscriber, #32426) [Link] > 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 Posted Jul 18, 2006 20:14 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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 Posted Jul 18, 2006 21:53 UTC (Tue) by NCunningham (guest, #6457) [Link] AFAIK, Suspend2 works on any machine swsusp works on - it now uses thesame lowlevel code, and they both use cpu hotplugging, so if one is broken, the other should be too.
Kernel Summit 2006: Software suspend Posted Jul 19, 2006 1:12 UTC (Wed) by lamikr (guest, #2289) [Link] How about adding suspend2 to kernel now as it is the best thingcurrently 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 Posted Jul 27, 2006 14:19 UTC (Thu) by rvfh (subscriber, #31018) [Link] > 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 Posted Jul 18, 2006 21:51 UTC (Tue) by NCunningham (guest, #6457) [Link] Yes, Rafael's fixes have helped.
It's not so much that I like my 'out of tree playfield', as that dealing
But he had the foresight and understood the process well enough to fork
Given the above, I don't know what the way ahead is from here, but if
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 22:32 UTC (Tue) by maks (subscriber, #32426) [Link] > 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,
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 Posted Jul 18, 2006 23:11 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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 Posted Jul 19, 2006 16:55 UTC (Wed) by christian.convey (guest, #39159) [Link] 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 Posted Jul 19, 2006 20:02 UTC (Wed) by bojan (subscriber, #14302) [Link] > 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 Posted Jul 19, 2006 21:21 UTC (Wed) by christian.convey (guest, #39159) [Link] 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 Posted Jul 18, 2006 11:04 UTC (Tue) by arjan (subscriber, #36785) [Link] 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 Posted Jul 18, 2006 11:37 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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
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 Posted Jul 18, 2006 12:47 UTC (Tue) by cventers (guest, #31465) [Link] > 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
Consider the fact that some of these driver bugs /have/ been around for
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 12:55 UTC (Tue) by bojan (subscriber, #14302) [Link] > 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
Kernel Summit 2006: Software suspend Posted Jul 18, 2006 19:26 UTC (Tue) by davej (subscriber, #354) [Link] 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] > 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] 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
Obviously I got the order wrong as far as "getting it working well"
Nigel
Kernel Summit 2006: Software suspend Posted Jul 21, 2006 15:02 UTC (Fri) by riteshsarraf (subscriber, #11138) [Link] I had the understanding that Free/Open Software was a platform where onecould 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
Look at Software Suspend 2. It has features, which AFAIK, no other OS
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
I don't think "backward compatibility" is going to allow innovation that
Kernel Summit 2006: Software suspend Posted Jul 27, 2006 20:12 UTC (Thu) by huaz (guest, #10168) [Link] : 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.
|
|||||||||||||