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

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

[Anonymous Coward]

If it's a hardware RAID controller then the kernel should "see" a single logical device it needs to wake up, and it can leave it to the controller firmware to wake up the drives in the correct order.

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.

Re:so how fast is fast..?

[Anonymous Coward]

That's too slow... osx takes a second or so. And the newest windows is trying to copy osx resume speed. Perhaps now, linux is copying windows resume.

WTF slashdot

[Anonymous Coward]

I'm in beta and I click classic which is on top it gets me to classic, hit the comments link and brings me back to beta and this is in a fucking loop. Stupid assholes, a website should be about the content itself not the bullshit eye candy which is taking space anyway. FUCKING RETARDS!!!

Re:WTF slashdot

[Janek Kozicki]

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