Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 9:17 UTC (Tue) by maks (guest, #32426)
In reply to: Kernel Summit 2006: Software suspend by NCunningham
Parent article: Kernel Summit 2006: Software suspend

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.

to post comments

Kernel Summit 2006: Software suspend

Posted Jul 18, 2006 10:27 UTC (Tue) by bojan (subscriber, #14302) [Link] (7 responses)

> 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 (guest, #32426) [Link] (6 responses)

> 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

Posted Jul 18, 2006 11:40 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

> <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 (guest, #32426) [Link] (1 responses)

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

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

Posted Jul 27, 2006 14:19 UTC (Thu) by rvfh (guest, #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] (5 responses)

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

Posted Jul 18, 2006 22:32 UTC (Tue) by maks (guest, #32426) [Link] (1 responses)

> 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

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] (2 responses)

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] (1 responses)

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