Announcement

Collapse
No announcement yet.

Linux 4.7 Adds ARM64 Support For Hibernate & Suspend-To-Disk

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 4.7 Adds ARM64 Support For Hibernate & Suspend-To-Disk

    Phoronix: Linux 4.7 Adds ARM64 Support For Hibernate & Suspend-To-Disk

    The ARM64 architecture updates were sent in on Monday for the Linux 4.7 kernel and do contain some notable changes...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    At first I was like "hmm that's cool" but immediately after I'm like "wait... why?" An idle ARM platform often uses less power than an x86 system on standby. I don't see the point of hibernation. You might be saving a couple watts of power at best. I suppose it might be useful if you've got some power hungry USB devices though.

    Also, what's the difference between hibernation and suspend-to-disk? The way the article is written, it seems there's a distinct difference. Does StD work without using a swap partition?

    Comment


    • #3
      Originally posted by schmidtbag View Post
      At first I was like "hmm that's cool" but immediately after I'm like "wait... why?" An idle ARM platform often uses less power than an x86 system on standby. I don't see the point of hibernation. You might be saving a couple watts of power at best. I suppose it might be useful if you've got some power hungry USB devices though.

      Also, what's the difference between hibernation and suspend-to-disk? The way the article is written, it seems there's a distinct difference. Does StD work without using a swap partition?
      Battery-powered devices man. Hybernate is crucial there (your phone lives most of its power-on time in a hybernation-like state), STD probably less, but still useful.

      Also, not all ARM devices are crappy and low-power. Just think of the snapdragons that needed a heatpipe and/or massive downclocking to not melt down.

      Comment


      • #4
        Originally posted by starshipeleven View Post
        Battery-powered devices man. Hybernate is crucial there (your phone lives most of its power-on time in a hybernation-like state), STD probably less, but still useful.
        That "hibernation-like state" is standby, which is not the same thing and to my knowledge linux has already supported for ARM. A hibernated device is legitimately powered off, and therefore will not respond to input interrupts. A device (such as a phone) on standby can still respond to things like calls. The ARM CPU by itself hardly uses any power at all when on standby. Unlike x86, ARM doesn't have leaky transistors. Most of the power your phone uses are because other devices, like wifi or GPS. My phone will last a full week if I turn wifi off, lasts about 4 days with GPS enabled, and about 2 days if wifi is enabled. So yeah, hibernation could help with battery life, but once you're hibernated, all those devices are offline. You'd be better off just disabling them through the OS and put the device on standby.

        Also, not all ARM devices are crappy and low-power. Just think of the snapdragons that needed a heatpipe and/or massive downclocking to not melt down.
        I never said or implied they are. But when you need active cooling for an ARM device, there's a good chance that hibernation is not a priority. Again - might as well go for standby. At least that responds quicker.
        Last edited by schmidtbag; 17 May 2016, 10:49 AM.

        Comment


        • #5
          Originally posted by schmidtbag View Post
          That "hibernation-like state" is standby, which is not the same thing and to my knowledge linux has already supported for ARM. A hibernated device is legitimately powered off, and therefore will not respond to input interrupts.
          WoL, or some other protocol to wake it up again. Smartphones aren't the main target for these patches, I know.

          Originally posted by schmidtbag View Post
          But when you need active cooling for an ARM device, there's a good chance that hibernation is not a priority.
          Heatpipes aren't active cooling. Still technically passive even if they are not just a lump of metal.

          Comment


          • #6
            Originally posted by starshipeleven View Post
            WoL, or some other protocol to wake it up again. Smartphones aren't the main target for these patches, I know.
            Hasn't ARM been notoriously difficult relating to WoL? Also, I thought WoL didn't work on hibernate? I could be wrong; I don't do it myself. I always hear about people whining that WoL doesn't work on certain devices. But yeah, phones likely aren't the main target. I don't think servers are either. It's definitely a niche - probably stuff like ARM-based laptops or HTPCs. But even then, I'd rather do standby on an HTPC. I want it up and running as fast as possible. A lot of ARM devices don't have SATA III speeds.

            Heatpipes aren't active cooling. Still technically passive even if they are not just a lump of metal.
            Yeah, I probably should've thought that part through a little more. I guess I'm just so used to seeing ARM devices that need little to no cooling so I just automatically thought of heat pipes as being active (but I know they're not).

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Hasn't ARM been notoriously difficult relating to WoL?
              WoL has notoriously been an unreliable bitch on any platform.
              That said, I was thinking at some WoL-like thing where the eth (or whatever other MCU on the board) receives something and decides to go thaw the system.
              In embedded world there is stuff like that. Obviously not anywhere near standard, all custom.

              Also, I thought WoL didn't work on hibernate?
              Nah, it's stuff done at low level, usually by board firmware and network controller firmware, so it *SHOULD* theoretically work, but in most cases... it does not do so reliably. https://www.hmisource.com/otasuke/qa...rnation_e.html

              Like this guy, it works on sleep and hybernate, but not on shutdown. I mean like.. WTF?!
              http://www.overclock.net/t/998775/wa...s-shutdown-not


              Afaik win8 removes this ability alltogether (all praise MS and their infinite wisdom), but the hardware per-se still can do whatever.

              I never investigated WoL on Linux and I'm not going to, I'm sure that in embedded they can get what they need with hacks if necessary.

              It's definitely a niche - probably stuff like ARM-based laptops or HTPCs.
              Obviously IoT and maybe NAS and mediacenter and friends.

              ARM-based laptops and PCs are a dream I'd like to see come true, but I doubt it's the main goal of this patch.

              A lot of ARM devices don't have SATA III speeds.
              ARM64 chips usually have fast flash controllers, Sata3, PCIe and/or whatever, and are too expensive/powerful to go in low-end devices.
              You're still comparing them with crappy ARM devices.

              AFAIK the only ARM64 chips around in any appreciable quantity are those in some high-end smartphones. AMD will make their own theoretically.
              Last edited by starshipeleven; 17 May 2016, 11:57 AM.

              Comment


              • #8
                Originally posted by schmidtbag View Post
                Also, what's the difference between hibernation and suspend-to-disk? The way the article is written, it seems there's a distinct difference. Does StD work without using a swap partition?
                IIRC, there are multiple ways how this could be implemented. E.g, "hibernate" could be cutting the power to all the hardware bits expect RAM. This is done in some machines (laptops when you close the lid). Then suspend to disk already tells everything. Basically you put the sate into a swap file which is on disk and you get no power consumption while in this mode.

                Having system to keep RAM in low power states still consumes power, but saves tons of battery, provided very fast load times. Think smartphones and during the night. Most of time it can be hibernated to RAM until something triggers to awake the hardware.

                Comment


                • #9
                  davidlt
                  You're confusing hibernation with standby (or specifically, "suspend to RAM"). Again, not the same thing as hibernation. Suspend/sleep/standby can be immediately resumed via interrupts, but hibernation can't. With hibernation the system is completely off. If you hibernate an x86 computer, you can boot into a different OS or go into BIOS. You can't do this with standby. Standby also doesn't require a swap partition, but hibernation does.

                  Comment


                  • #10
                    First, here are some links:



                    OK, why is this useful for mobile devices?
                    It enables very fast boot (snapshot restore), so that hibernating a device doesn't incur such a large resumption penalty (which is always a major consideration for any of these types of power management techs be it speedstep or sleep). If criu even becomes available, desktop linux will be able to do this (more generally, being able to swap out items at a process granularity would make these kinds of issues easier, I should think).
                    It can, if the platform supports it, act upon certain inputs (like, WoWLAN). I could see this being really useful with a modified version of Android's Doze (puts device to sleep, but periodically awakens device to perform certain tasks like checking for high priority email/texts, emergency alerts, etc).
                    Given how much faster mobile storage has become, even this sort of operation should be very, very quick.

                    Comment

                    Working...
                    X