Re: [ 00/10] [Suspend2] Modules support.

[Matthew Garrett <mgarrett@chiark.greenend.org.uk>]

Lee Revell <rlrevell@joe-job.com> wrote:

> Follow up - do we have a rough idea how bad the suspend problem is, like
> approximately what % of laptops don't DTRT and just suspend when you
> close the lid?

It's arguable whether "just suspending when you close the lid" is
actually DTRT, but if you want "how many x86 laptops can we successfully
suspend and resume" then the number is between 80-90% for RAM and a
little more than that for disk (numbers based on Ubuntu, other
distributions don't have as much infrastructure for this right now).
This is based on doing hacky things like unloading all the network and
USB drivers before suspend, but by and large the driver situation is
much improved. The single biggest problem is video reinitialisation, and
that can't be solved in-kernel.

Based on actual hard, shipping evidence - swsusp works sufficiently well
that throwing it out and replacing it with a different implemenation is
entirely unnecessary. The two big advantages that suspend2 brings us are

1) Improved speed (an entirely fair objection to swsusp)
2) Graphical bling (and I think doing that in the kernel is pretty
insane)

Pavel's proposed plan brings us both of those without massive kernel
changes, so I'm really quite tempted to go with that. From a
distribution standpoint, integrating it is very straightforward.

(By and large, the biggest problem is repeated kernel regressions that
hit suspend in bizarre ways. This doesn't get picked up on quickly
because almost nobody is using this code, because "everyone knows" it
doesn't work. Except it /does/. What we need is for distributions to
actually work together on this, rather than everyone trying to fix the
same problems independently, each coming up with different solutions and
the world generally being a miserable place)

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/