Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Open Source Operating Systems Upgrades Linux

Linux 3.15 Will Suspend & Resume Much Faster 117

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)."
This discussion has been archived. No new comments can be posted.

Linux 3.15 Will Suspend & Resume Much Faster

Comments Filter:
  • Caution (Score:5, Insightful)

    by arth1 ( 260657 ) on Saturday April 12, 2014 @04:57PM (#46735713) Homepage Journal

    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 (Score:5, Insightful)

      by K. S. Kyosuke ( 729550 ) on Saturday April 12, 2014 @05:14PM (#46735777)
      Something tells me that machines with a heavily RAID-ed disk subsystem are not exactly your usual candidates for frequent power cycles.
      • Re: (Score:3, Informative)

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

      • by sjames ( 1099 )

        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.

      • Also, consumer (and mass storage) grade 7200 rpm drives have significantly lower power surge than 15K drives.

      • by Anonymous Coward

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

        In my case - which you may dismiss as anecdotal - they are. We live in the countryside, and so power outages are common, especially during the summer. So we have a pair of UPSs backing up the servers (about 1½ hours capacity with all disks spinning). The servers are three Synology boxes, all with RAID - two are the two-bay type, one is a four-bay type, and all drive bays are occupied with 3TB and 4TB drives, totalling 14TB in RAID (raw 28TB). Another pair of smaller UPSs keep the networking gear going,

    • by RulerOf ( 975607 )
      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
      • by epyT-R ( 613989 )

        Uh.. x86 has been able to do this for over a decade now.. It's linux that's catching up. It's power management hasn't been that great.

      • by arth1 ( 260657 )

        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

      • After all, I've gotten pretty used to putting a device "to sleep" and "waking it up" instantly.

        This is a UI issue. Mobile devices can simply turn off the display before they've actually entered sleep mode. How would you know? Your PC could do the same thing, but there would be fans running and lights flashing, so you'd be aware that it was trying to trick you.

    • Re:Caution (Score:5, Informative)

      by SpankiMonki ( 3493987 ) on Saturday April 12, 2014 @05:26PM (#46735859)

      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.

    • by Anonymous Coward

      Yes, and it matters a whole lot more to us power users with lots of data! Even with large 3TB+ hard drives, it can take lots of drives to fit all of our data. My motherboard has 6 SATA ports and I have an SATA controller with 4 extra ports. Waking up 10 drives at the same time is an extra 20A of load or so on the 12V rail. That requires a fairly solid, high quality/high current PSU (admittedly I do have that).

    • Re: (Score:2, Informative)

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

      Spinning drives... how quaint!

  • by Anonymous Coward on Saturday April 12, 2014 @05:18PM (#46735805)

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

    • My antique Latitude D600 needs a whopping 5 seconds to wake up, which is waaaay too long </sarcasm>
      So yeah... How much more improvement do you need?
    • I have an x230 that I put a Corsair SSD in. It's running Ubuntu 13.10, so I guess it's running a 3.11.something kernel. On resume I can see the kernel block for 10+s (by the timestamps in dmesg) waiting for my SSD to get its act together. Screen is on, lockscreen is displayed ... but I can't enter a password because the entire system is waiting on the disk.

      It sounds like I will benefit from this.

      • sounds more like you need a better disk or distro, my 5400rpm hdd resumes debian sid (3.13.7-1 but also 3.11 when it ran wheezy) in 1-2secs and i can type the password and get on with work instantly.

    • 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

    • how much more improvement can you get?..

      Well, you could convince the sensors applet and the clock applet to wake up from suspend properly instead of randomly consuming all CPU cycles, preventing the gui from awakening.

    • by Trogre ( 513942 )

      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.

      • My Ubuntu box has 100% reliable resume, but it only goes to sleep once or twice and then it refuses to go to sleep again. But I suspect that's just an Ubuntu problem :)

  • not fast (Score:3, Insightful)

    by lgalindo ( 530228 ) on Saturday April 12, 2014 @05:19PM (#46735813) Homepage
    will be happy if it does it right ...
    • That largely depends on drivers, IOW: the willingness of hardware vendors to do things right.
      • Re:not fast (Score:4, Interesting)

        by SuricouRaven ( 1897204 ) on Saturday April 12, 2014 @06:39PM (#46736285)

        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.

        • Or just bricks the machine
        • 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 ASP
  • by Janek Kozicki ( 722688 ) on Saturday April 12, 2014 @05:29PM (#46735875) Journal
    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... [ubuntu.com]
    # 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... [soylentnews.org] . The only working kernel was 2.6.29 with tuxonice [soylentnews.org]
    • I have had excellent results with suspend and hibernate on various laptops. I rant a lot about brokenness of OSS, but this is an area where Linux actually works really well today.

      What kind of problems are you having?

      • It simply doesn't resume. HIbernation always works. You can see it on videos:

        http://www.pg.gda.pl/~jkozicki... [pg.gda.pl]
        The *.mov files are records from hibernation/suspend attempt. They have polish names, ignore that. You can see that it reboots again right at the end of resume, then boots into log-in screen

        I think it is related to my hardware: dual Xeon E5-2687Wv2, 64 GB of RAM, motherboard SUPERMICRO MBD-X9DRI, GPU nvidia GTX 780 (only debian approved nonfree drivers, no blobs from nvidia.com)
    • What's the point if suspend resume doesn't work at all?

      Besides, this is old news. Our new and better site beat slashdot: https://soylentnews.org/articl... [soylentnews.org]

      Well, if you'd bothered to read TFA, you would have known that there was a merge last night that specifically benefits the resume process. While it may or may not help you specifically, it is definitely NOT old news. BTW, your "new and better site" makes no mention of this at the time of this writing.

    • you'll get a headache if you keep nutting the client and the server
  • by Cley Faye ( 1123605 ) on Saturday April 12, 2014 @05:36PM (#46735905) Homepage
    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.
  • by Antique Geekmeister ( 740220 ) on Saturday April 12, 2014 @05:37PM (#46735915)

    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.

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

      So is OpenRC.

    • by evilviper ( 135110 ) on Saturday April 12, 2014 @06:35PM (#46736257) Journal

      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.

    • Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot. The BIOS slowness was mostly due to heaps of unnecessary memory tests and diagnostics anyway. Once those stop happening, there's not much time spent getting ready for booting at all. Windows 7 on my Windows 8-shipped laptop with an SSD comes up to a ready-to-go desktop in less than 10 seconds from power on. The BIOS speed obstacle is largely solved on new machines.
      • I'm glad it's improved for your laptop: I agree that it's gotten better especially for laptops and SSD drives. I also agree that UEFI is helping. Unfortunately, I've tended to deal with servers, where it is _not_ a solved problem.

      • by arth1 ( 260657 )

        Modern UEFI BIOS implementations, even when booted to CSM mode, tend to spend an extremely short amount of time doing work pre-boot.

        I admin several UEFI booting servers, and they can take several minutes probing and verifying hadware and firmware before the boot commences.
        The switch from BIOS to UEFI has not helped one bit - rather the opposite, as the drive containing the UEFI boot binaries has to be enumerated and verified before the binaries can be loaded.

        Keep in mind that the kernel needs to not only work with PCs, but servers and embedded devices (where there's neither BIOS nor UEFI). Making things work well for 80% and to hell wi

  • by Antonovich ( 1354565 ) on Saturday April 12, 2014 @05:48PM (#46735981)

    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.

    • You know, an idle kernel doesn't use much of your battery life. Bulky programs that crunch and munch on the CPU do. Saying, "Linux this" and "OS X that" doesn't make sense unless you know that it boils down to the kernel and kernel drivers. Have you run powertop to examine exactly which processes and drivers are responsible for draining your battery? Have you followed the recommendations given by powertop?

      Finally, have you considered the possibility that your battery might be crap, and that a higher capaci
      • by Hymer ( 856453 )

        Systemd: the PulseAudio of init systems

        Is this a good thing or a bad thing ?

      • I tried powertop a few years ago but never had much success, though that was probably v1. I'll give it another try, thanks for the heads up.

        A friend dropped the laptop about a year ago (it was an "accident", though he was drunk...). It didn't seem to make a difference for the first 8-9 mths but it weakened the lid/screen joint and with 12 mths of opening/closing has started to degrade seriously. I could spend many hours to try and patch it up but I've never had much success with anything more complicated th

    • Long post, but very relevant.

      I recently got a Thinkpad X240 with the large batterypack (total of 96wh), + an extra batterypack of 23wh, have had it for 2 months now. It's running ubuntu 13.10 and i'm getting about 10-12hours of active usage from it daily. I also always bring the extra batterypack in case of emergency.

      Power consumption and batterylife with the large pack.

      • 2.8w (~34hours battery) - Lowest idle i've gotten it to (essentially nothing running, flight-mode activated so no radios or net
      • Hey, thanks heaps for that. The X240 looks pretty much exactly like what I am after, and Lenovo (here in France) seems to let you mix and match upgrades which is seriously cool. What upgrades did you make with your system to get those numbers? Did you up the RAM to 8GB? Do you have an SSD (on top of the cache disk)? What proc do you have? How much extra weight does the larger battery pack add? 12.5" will be noticeably smaller than my current 14" - how do you find the screen?
        Thanks!

        • Hi!
          I basically maxed everything relating to hardware, didn't select the I7 cpu though, I5-4300u has the virtualization support i sometimes need, and i prefer to have more battery instead of peak performance. This laptop could possibly use less energy under some workloads if selecting the I3 cpu, i'm not certain though.
          • Hardware list:
          • I5-4300u
          • 8GB ram
          • FHD IPS Display (1920x1080)
          • 256GB SSD, Cache option disappears when you select ssd and/or 3g card
          • touchpad with NFC and fingerprint reader (touchpad is a bit fun
  • by tdelaney ( 458893 ) on Saturday April 12, 2014 @06:16PM (#46736169)

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

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

  • by mugurel ( 1424497 ) on Saturday April 12, 2014 @06:56PM (#46736353)
    Linus Torvalds is now said to suspend (but not resume) key linux developers up to 10 times faster.
  • by Anonymous Coward

    People don't have any real faith in Linux distros to properly suspend or resume in the first place, much less the speed at which they perform. That needs to be more in like with Windows or OS X before they can even begin to improve its speed.

    • by Teun ( 17872 )
      I see you are mixing up the capabilities of Linux and the hardware.

      Linux can handle it fine but some hardware manufacturers don't disclose their methods.

  • parallelism (Score:4, Interesting)

    by lkcl ( 517947 ) <lkcl@lkcl.net> on Saturday April 12, 2014 @07:58PM (#46736749) Homepage

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

    • That's an interesting point. As a Linux user for many years, I never cared about boot or resume time. That's only mattered recently, as handheld devices have become quite useful. My servers and desktop stay powered on for years at a time, so I never cared how many seconds a reboot takes. Obviously a tablet is different. With a tablet, I do care, I want it to start up and shutdown quickly.

    • by epyT-R ( 613989 )

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

      • by dbIII ( 701233 )
        He's missing a "y" in there somewhere and describing what happens when problems reading optical media on such systems bring the things to a screeching halt :)
      • by lkcl ( 517947 )

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

        someone else answered about OSX. NT, based on the MACH kernel, has been fully re-entrant and multi-threaded for a looong time. also, given that the service control manager (which is a parallelised start/stop daemon service) is fully parallelised i'd be incredibly surprised if the same attention to detail wasn't also carried through on device-driver initialisation as well. although.... the only evidence against that is the "Debug Startup" mode, which initialises drivers in sequence (and shows you the sequ

  • WTF slashdot (Score:2, Informative)

    by 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!!!

  • Sorry but the Suspend feature of Windows - called BSOD - is almost instantaneous.
  • My Clevo laptop is a Pentium-D and it boots Debian with encrypted root faster than Win7 can resume on my $$$ Core-i5 Lenovo.

    So not sure we even need a faster suspend/resume, which is almost instant.

  • How's the Haswell/Maxwell support coming along? ;-)

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...