Kernel Summit 2006: Software suspend
Kernel Summit 2006: Software suspend
Posted Jul 18, 2006 8:38 UTC (Tue) by NCunningham (guest, #6457)Parent article: Kernel Summit 2006: Software suspend
> 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.
Posted Jul 18, 2006 9:17 UTC (Tue)
by maks (guest, #32426)
[Link] (14 responses)
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.
Posted Jul 18, 2006 10:27 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (7 responses)
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.
Posted Jul 18, 2006 10:54 UTC (Tue)
by maks (guest, #32426)
[Link] (6 responses)
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).
Posted Jul 18, 2006 11:40 UTC (Tue)
by bojan (subscriber, #14302)
[Link] (2 responses)
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.
Posted Jul 18, 2006 11:47 UTC (Tue)
by maks (guest, #32426)
[Link] (1 responses)
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..
Posted Jul 18, 2006 20:14 UTC (Tue)
by bojan (subscriber, #14302)
[Link]
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.
Posted Jul 18, 2006 21:53 UTC (Tue)
by NCunningham (guest, #6457)
[Link]
Posted Jul 19, 2006 1:12 UTC (Wed)
by lamikr (guest, #2289)
[Link]
Posted Jul 27, 2006 14:19 UTC (Thu)
by rvfh (guest, #31018)
[Link]
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!
Posted Jul 18, 2006 21:51 UTC (Tue)
by NCunningham (guest, #6457)
[Link] (5 responses)
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
Posted Jul 18, 2006 22:32 UTC (Tue)
by maks (guest, #32426)
[Link] (1 responses)
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 :)
Posted Jul 18, 2006 23:11 UTC (Tue)
by bojan (subscriber, #14302)
[Link]
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.
Posted Jul 19, 2006 16:55 UTC (Wed)
by christian.convey (guest, #39159)
[Link] (2 responses)
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.
Posted Jul 19, 2006 20:02 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (1 responses)
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.
Posted Jul 19, 2006 21:21 UTC (Wed)
by christian.convey (guest, #39159)
[Link]
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.
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.Kernel Summit 2006: Software suspend
> It's a pain that you like your out of tree playfield instead of fixing the in tree solution.Kernel Summit 2006: Software suspend
> I think that's not fair. The in-tree solution doesn't offer many capabilities Suspend2 does. Kernel Summit 2006: Software suspend
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.
> <snipp unrelated talk about other os>Kernel Summit 2006: Software suspend
> So does swsusp - it's mostly a driver issue. As I can verify on my dual core laptop.Kernel Summit 2006: Software suspend
> swsusp works fine here (mem, disk) on x60 once you set an bios sata option to compatible.Kernel Summit 2006: Software suspend
AFAIK, Suspend2 works on any machine swsusp works on - it now uses the Kernel Summit 2006: Software suspend
same lowlevel code, and they both use cpu hotplugging, so if one is
broken, the other should be too.
How about adding suspend2 to kernel now as it is the best thingKernel Summit 2006: Software suspend
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...
> nobody needs again 2 in kernel solutions.
Kernel Summit 2006: Software suspend
Yes, Rafael's fixes have helped.Kernel Summit 2006: Software suspend
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.
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.
someone wants to suggest one (and it doesn't kill me in the process :>),
I'm willing to listen.
> Given the above, I don't know what the way ahead is from here, but ifKernel Summit 2006: Software suspend
> someone wants to suggest one (and it doesn't kill me in the process :>),
> I'm willing to listen.
that was already a very good start.
> the hole suspend2 base is much to huge to get gobbed on once. even ubuntu cares about driver fixes these days.Kernel Summit 2006: Software suspend
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.Kernel Summit 2006: Software suspend
> Second, ensure the drivers are up to snuff.Kernel Summit 2006: Software suspend
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.Kernel Summit 2006: Software suspend