Numbers? See first post. Also see link in second post about how little time kernel takes to resume. Rest of this time is consumed by userland -- pm-utils and ubuntu scripts, videocard resuming and so on. Fixing this need optimisation of whole stack and some additional work. Videocard issues are fixed by moving modesetting to kernel (there is some old video on Phoronix showing differences). Intel modesetting is available on Fedora for example. I am vaguely aware of other issues. Linux desktop stat()s too much files, waits too much and not paralleises things enough. Matthew Garrett's presentation from LUGRadio Live depicts sorry state of linux suspend and resume. So, there is hardware like OLPC XO-1, where optimised stack allows resuming in 300 ms. There are Macs, which are for all practical purposes identical hardware, yet with optimized OS X they resume in 3 seconds. And finally, there are Ubuntu systems, which resume slowly, ten times longer that macs, hundred times slower than XO-1. This bug is about deficency in Linux, about pointing to a problem (like famous bug #1). I'm aware that it cannot be fixed by just integrating other's work, but some development should be done by Ubuntu devs.
-- resume from STR is very slow on Thinkpad z61t https://bugs.launchpad.net/bugs/135083 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
