Linux 3.15 Will Suspend & Resume Much Faster

An anonymous reader writes "The Linux 3.15 kernel now in its early life will be able to suspend and resume much faster than previous versions of the Linux kernel. A few days ago we saw ACPI and Power Management updates that enable asynchronous threads for more suspend and resume callbacks. Carrying out more async operations leads to reduced time for the system suspend and then resuming. According to one developer, it was about an 80% time savings within one of the phases. On Friday, work was merged that ensured the kernel is no longer blocked by waiting for ATA devices to resume. Multiple ATA devices can be woken up simultaneously, and any ATA commands for the device(s) will be queued until they have powered up. According to an 01.org blog post on the ATA/SCSI resume optimization patches, when tested on three Intel Linux systems the resume time was between 7x and 12x faster (not including the latest ACPI/PM S&R optimizations)."

Comments

Caution

[arth1]

There's a reason why RAID controllers tend to wake up drives sequentially. The power load of waking up 20 hard drives at the same time can be tremendous compared to the load when they're all spinning and purring. So you don't do that.

So I hope that power draw is taken into account, and that there will be options to limit the number of devices woken up simultaneously.

Re:Caution

[K. S. Kyosuke]

Something tells me that machines with a heavily RAID-ed disk subsystem are not exactly your usual candidates for frequent power cycles.

Re:Caution

[SpankiMonki]

There's a reason why RAID controllers tend to wake up drives sequentially.

And the RAID controllers will continue to do just that. All this change does is allow the kernel to continue resuming without having to wait for the device to report that it's ready. Any commands sent to the device in the meantime are queued.

Re:Caution

[Anonymous Coward]

Consider that Linux runs on everything. It's not unlikely that there are plenty of clusters out there that suspends whole computers when the power is not needed. If they are also filled with HDDs, then that use case arises.

I think it's a valid point, even though it's not very common.

Re:Caution

[sjames]

And if it's soft RAID or a ZFS pool?

so how fast is fast..?

[Anonymous Coward]

On my SandyBridge-era Thinkpad Edge, with:
- one 7200rpm Hitachi drive from ~ 2011 and
- one Intel SSD 525 from ~ 2013,
Debian Testing/Sid with kernel 3.13-1-amd64 wakes up from RAM sleep in 1s or so, thus extremely covenient so I never shutdown/hibernate.. how much more improvement can you get?..

Re:so how fast is fast..?

[elal1862]

Some perspective is needed here:
We're talking about almost-a-decade-old hardware running a current linux version. Yet it's still fast enough to resume within 5 seconds, boot in 45 seconds, start libreoffice in 4 seconds, IOW: still quite usable
My $200 says you can't run Mavericks on a (similar vintage!) PowerBook G4 with the same usability...

not fast

[lgalindo]

will be happy if it does it right ...

Re:not fast

[SuricouRaven]

And there lies the problem. Windows is very tolerant of badly-configured ACPI implimentations - it'll happily work even if half the configuration fields are wrong, as it simply ignores them and uses hard-coded suboptimal values. There's little incentive for OEMs to bother supporting any OS other than Windows, so typically once the firmware works for Windows it is considered good enough. All is well, until we stick linux on it - and linux then follows the ACPI specification correctly, and fails horribly.

Re:Coupled with systemd and LinuxBios

[evilviper]

The third big software factor is the BIOS. "coreboot", formerly "LinuxBIOS", is blazingly fast compared to most proprietary BIOS's. It has made some inroads but is still not available for any commercial systems I can find. So no matter what is done in the other two factors, the BIOS is still a limiting factor of suspend and restore delays.

POST has to be performed by the BIOS when restoring from hibernation, but NOT suspend. So no, the BIOS is NOT a significant "limiting factor of suspend and [resume]" operations.

In other news...

[mugurel]

Linus Torvalds is now said to suspend (but not resume) key linux developers up to 10 times faster.

parallelism

[lkcl]

.... um, it's 2014, the linux kernel is a critical part of the planet's internet infrastructure, is used in TVs, routers and phones all over the world, and you're *seriously* telling me that its internals aren't fully parallelised? i thought the linux kernel was supposed to be a leading example of modern operating system design and engineering.

Re:WTF slashdot

[Janek Kozicki]

Just go to a new and better site: http://soylentnews.org/