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

[RulerOf]

But what system with dozens of hard drives in it would be entering and exiting S3 constantly anyway?

You might do power saving on hypervisor hosts, but on a SAN? I can't think of a scenario where it makes a lot of sense... but perhaps I'm just lacking the proper imagination :P

On topic: I think this is awesome. I want to be able to suspend my machine and wake it up whenever I feel like it, with VMs shuffling around waiting for me to pick up a different tablet, or sit at a different desk. x86 has a lot of catching up to do. After all, I've gotten pretty used to putting a device "to sleep" and "waking it up" instantly. It'd be nice if my computer could do the same thing... even if it's only in spirit. Of course, an S3/4/5 is a much deeper sleep than my phone or tablet ever enters while it's powered on, AFAIK.

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

[KiloByte]

If your UPS dies, a suspended machine is screwed just the same. There's rather little point in suspending a server: even ones that are off outside business hours are better off hibernating rather than suspending.

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:Caution

[sjames]

No, but but that one time a year when it does, it will be important to power the drives in sequence, not all at once.

The parallel start can still help though. There is a period of time between the inrush where the platters are at about the right speed but not yet stable. That's the point where powering the next drive on would be OK.

Re:Caution

[sjames]

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

Re:Caution

[arth1]

But what system with dozens of hard drives in it would be entering and exiting S3 constantly anyway?

It doesn't have to be constantly. Once is enough.

And you don't even need dozens of hard drives. Workstations with RAID 10 aren't all that uncommon. Being able to not have all drives spin up all at the same time would be beneficial, especially as the power supply gets older - even after as little as a year of constant use, the ability to handle high loads can easily be half or less of what it was when new.

While a motherboard BIOS will take care of spinning up drives sequentially at boot, it won't help for suspend.
So yes, having the ability to limit how much can be woken up at a time by the kernel would be beneficial.

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

Re:so how fast is fast..?

[thegarbz]

Think embedded. A device in complete sleep state can be powered for eons on a battery. Waking, doing whatever it needs to do and then going back to sleep waiting for the next interrupt is critical to battery life. In the micro-controller world the difference in battery life of 2 seconds of wake-up time can mean the difference between swapping out your batteries in a day or in a year. I have not very fond memories of counting how many cycles various assembly instructions will take to ensure the CPU on small micro controllers isn't awake for more than a few microseconds to meet some power requirements. The prospect of running a small linux machine the same way is quite interesting.

Re:so how fast is fast..?

[Trogre]

A more useful metric, IMO, is how reliable the suspend/wakeup cycles are. For example, a particular Fedora 16 box I ran would suspend/resume with 100% reliability. That is, it would suspend every time you asked it to, and wake up every time you asked it to. Another Fedora 20 machine has 100% sleep and 0% wake. ie it goes to sleep and NEVER WAKES UP without a hard power cycle. Another machine had 100% sleep and about 75% wake, which is again utterly useless.

Re:so how fast is fast..?

[elal1862]

Hey, it's not my problem that Apple dropped PPC support with Snow Leopard *smirk*

Re:so how fast is fast..?

[Samizdata]

Stop reminding me, you insensitive clod!

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:not fast

[YoopDaDum]

The sloppiness in the PC ACPI world can also bite Windows too. You can find nice Asrock mini PCs based on laptop hardware. If you look at a Tom's hardware review of the Asrock VisionX 420, with a mobile core and mobile AMD GPU, you'll see that it consumes 28W at idle. This is crazy high for what's in effect a mobile laptop in small form factor box. One of the big reason is that the system ACPI says that PCIe ASPM (the low-power mode of PCIe) is not supported. Configuring laptop-mode on Linux and forcing ASPM results in idling at ~12.5W only, and a quieter box. Enabling ASPM in power saving mode alone saves ~8W, the rest is due to other suboptimal Windows defaults I guess.

So IMHO the "let's do the minimum and ship" to save a buck approach of PC vendors hurts Windows and linux both. On the Windows side you'll usually get something considered good enough for its product class (here power was not considered as relevant for an HTPC it seems) but likely not optimal. On Linux you will get a mess by default because as you say vendors can't be bothered with it. But with some work you can actually get something quite good.

It doesn't work at all.

[Janek Kozicki]

What's the point if suspend resume doesn't work at all?

Here's my SLEEP script, in which I am testing various kernels:

#!/bin/bash

logger "========== touch forcefsck ==========="
# if resume failed, then I want fsck (SSD disks, so it's just few seconds)
touch /forcefsck
/bin/sync
sleep 1

logger "hibernating"
# https://help.ubuntu.com/commun...
# it says there to try hibernating using various different methods

### method: 1 kernel 3,13,0 - fail, (2/6 success rate)
#/usr/sbin/hibernate

### method: 2 kernel 3,13,0 - fail, (3/6 success rate)
#/usr/sbin/s2disk

### method: 3 kernel 3.13.0 - fail, (2/6 success rate)
#echo platform > /sys/power/disk
#echo disk > /sys/power/state

### method: 4 kernel 3.13.0 - (3/6 success rate)
### kernel 3.2.0 - 80% sukcesów 20% fail (over 80/100 success rate - currently in use)
### kernel 3.12-bpo - (0/1) success rate)
echo shutdown > /sys/power/disk
echo disk > /sys/power/state

sleep 5
logger "restart network"
## something screws networking after resume
/etc/init.d/networking restart
sleep 2

## also UPS connection is screwed (sometimes I need to disconnect and reconnect the USB cable)
sleep 5
/etc/init.d/nut-client stop
sleep 5
/etc/init.d/nut-server stop
sleep 5
/etc/init.d/nut-server start
sleep 5
/etc/init.d/nut-client start
sleep 5
# don't mess with clock /etc/init.d/ntp restart
logger "resume complete"

Besides, this is old news. Our new and better site beat slashdot: https://soylentnews.org/articl... . The only working kernel was 2.6.29 with tuxonice

Re:It doesn't work at all.

[jones_supa]

Sorry to hear about that. Probably a good idea to file a bug report at https://bugzilla.kernel.org/ (if you didn't already).

I'd rather have "easier to debug"

[Cley Faye]

My main issue with suspend with my laptop is that it never wake up. Now it can be faster at not waking up, wow.
I'd rather have a way to generate log and find the issue relatively easily.

Coupled with systemd and LinuxBios

[Antique Geekmeister]

There are quite a few things that slow booting systems. Systemd is _supposed_ to take a lot of the slow, sequential starup out of the actual system daemons: it will be a while before it's really working well for critical, production systems, but that can take minutes off of startup time in a large environment. Note, also, that much of its "startup advantage" is illusory. Daemons are told to start up, and systemd keeps them starting up, but they're not necessarily available for quite some time after startup. This especially applies to databases and bulky Java applications.

The kernel startup is another big factor. Scanning for, assessing, and activating drivers for all the potentially available hardware is a slow and painful process because the upstream specifications are poorly documented, and even violated by many vendors. Many of them are legacy drivers and could in theory be discarded in most production kernels, but doing so can be quite tricky and hard to test for enough strange configuration cases.

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.

Re:Coupled with systemd and LinuxBios

[whoever57]

Systemd is _supposed_ to take a lot of the slow, sequential starup out of the actual system daemons:

So is OpenRC.

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.

Who cares?

[Antonovich]

Tell me when they can make my laptop last for more than an hour without mains and I'll be happy. I need to upgrade but battery life under Linux is so woeful I can't justify spending the ridiculous prices they are asking these days. To get a similar laptop to the 3 yr old one I have (at least in terms of size, weight, memory and disk) I would have to spend the same amount today as back then. Where is Moore's law again? Even though I can't afford one, I was looking at the Dell XPS 13 but for a couple of hundred more (for similar specs) I could get a macbook air and have *double* the battery life with osx. I would even consider it if I could run Linux on it and get similar battery life to osx... But alas, I read it sucks just as much as on all other machines.

Does it fix this issue?

[tdelaney]

https://github.com/OpenELEC/Op...

Just determined in the last week to be due to async suspend/resume. From the various reports, oretty much all Intel hardware is affected.

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:parallelism

[epyT-R]

You're assuming a lot there. How would you know if osx or windows NT kernels are 'fully parallelized'? Have you seen the source?

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/