Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
Linux

Linux 6.14 Brings Some Systems Faster Suspend and Resume (phoronix.com) 46

Posted by EditorDavid from the Linux-lifestyles dept.
Amid the ongoing Linux 6.14 kernel development cycle, Phoronix spotted a pull request for ACPI updates which "will allow for faster suspend and resume cycles on some systems."

Wikipedia defines ACPI as "an open standard that operating systems can use to discover and configure computer hardware components" for things like power management and putting unused hardware components to sleep. Phoronix reports: The ACPI change worth highlighting for Linux 6.14 is switching from msleep() to usleep_range() within the acpi_os_sleep() call in the kernel. This reduces spurious sleep time due to timer inaccuracy. Linux ACPI/PM maintainer Rafael Wysocki of Intel who authored this change noted that it could "spectacularly" reduce the duration of system suspend and resume transitions on some systems...

Rafael explained in the patch making the sleep change:

"The extra delay added by msleep() to the sleep time value passed to it can be significant, roughly between 1.5 ns on systems with HZ = 1000 and as much as 15 ms on systems with HZ = 100, which is hardly acceptable, at least for small sleep time values."
One 2022 bug report complained a Dell XPS 13 using Thunderbolt took "a full 8 seconds to suspend and a full 8 seconds to resume even though no physical devices are connected." In November an Intel engineer posted on the kernel mailing list that the fix gave a Dell XPS 13 a 42% improvement in kernel resume time (from 1943ms to 1127ms).
This discussion has been archived. No new comments can be posted.

Linux 6.14 Brings Some Systems Faster Suspend and Resume More

Linux 6.14 Brings Some Systems Faster Suspend and Resume

Comments Filter:
  • I'm all for code reviews and whatnot, but this one seems like a very, very negligible improvement. Are there actually instances where a second or two delay when purposely putting your machine into sleep is a deal breaker for some people? After all, some Windows users are used to waiting minutes - sometimes hours - for their machine to sleep/shutdown/restart after hitting the button.

    • Re: (Score:3, Insightful)

      by Valgrus Thunderaxe ( 8769977 )
      I've never seen suspend/resume actually work on Linux, ever.

      • Re: Sounds like splitting hairs to me? (Score:4, Insightful)

        by BeepBoopBeep ( 7930446 ) on Sunday January 26, 2025 @01:18PM (#65119891)
        Yup Linux on laptop even the XPS blows. Never consistent. Sometimes it resumes. Sometimes it does. Sometimes it does but the keyboard is dead.

      • I've never seen suspend/resume actually work on Linux, ever.

        I use it every day and have no problems except for one which pops up on rare occasions. My monitor won't wake up and there will be a message about the CPU not responding after so many seconds. Then I have to power down the entire machine and bring it back up. Aside from that one quirk, suspend works as expected. My power setting is suspend after 15 minutes.

        The issue seems to be related to the Nvidia driver, but it doesn't happen often enough for me to worry about.

      • Re:Sounds like splitting hairs to me? (Score:5, Funny)

        by LordHighExecutioner ( 4245243 ) on Sunday January 26, 2025 @01:53PM (#65119955)
        Suspend works here....but without resume. The function should be renamed as "bury".

      • Re: (Score:2)

        by ichthus ( 72442 )

        I've never seen suspend/resume actually work on Linux, ever.

        I use it every day on a Dell XPS 15. It works, but it does take a few seconds -- maybe 5 if I have a thunderbolt dock plugged in.

      • Re: (Score:3)

        by Samare ( 2779329 )

        Suspend works fine here, it takes less than 1 second to suspend or resume.

        Hibernation works too, the only con for it is that the hard disk spins down then back up and finally down again.
        Since systemd v255 and mkinitcpio v38, you just need to have a big enough swap space without having to do any configuration.

        This is on a 2014 i3 with 12GB RAM, 2 SSDs and 1 hard disk.

      • "you're holding it wrong"
      • I had this problem too on my desktop until I stopped using AMD systems. Intel based systems at least seem to have a functioning suspend and resume on desktop systems. Even my nvidia card now works through the process - well unless you forget and leave stable diffusion running, then their GPU crashes but on resume you can still ssh in to reboot the machine.

        Aaah, progress.

      • I'm often putting my 2008 Latitude to sleep when I move from room to room because the battery is dead since a year or so, and the only issue I had once in a while is slower resume because the MD RAID 1 volume for swap has to resync before my session was restored (everything else is on btrfs RAID 1 volumes).
        As of kernel 6.11 (Devuan stable) I haven't seen a resync during boot, but it's somewhat early days.

      • Seems to be a highly random shit-show.

        On my (AMD) desktop, it mostly works, but sometimes requires pressing the power button (or WoL), the keyboard/mouse won't wake it. That one also has the "feature" (NVidia-related) that if it blanks the screen in preparation for locking, and you hit a key at that point, something gets fucked and the only way to get the screen back on is to dork around switching VTs for a while and occasionally kill the DM.

        On my (Chinese plus NVidia) laptop, it's a complete cluster. It

        • My shiny new Ryzen 5800U laptop suspends and resumes perfectly, as has every other Ryzen machine I have set up in recent memory.

          • lol- you're either a liar, or a virgin birth.
            Ryzen 4/5K laptops had a very high profile suspend problem for a long time, and that's ignoring the several times suspend has been broken across all x86 architectures several times in the 6.x series.

            Being you have a history of literally making shit up to make AMD shit seem like it's magical, I'm guessing the former is the case, not the latter.

      • Re: (Score:2)

        by spitzak ( 4019 )

        Has been working just fine for me, and I do find the time it takes to wake up annoying and it would be nice if it was faster.

        There is at least one bug: unplugging or pluggin anything into USB while it is asleep and it crashes when you try to wake it (in a loop that makes the fans turn on full-blast). Don't know if this is a common problem or what other operating systems do. Another problem might be that it sometimes wakes itself, going into sleep mode from suspend, though I have never been able to prove or

      • You don't get out much, do you.

      • Re: (Score:1)

        by jay age ( 757446 )

        Of course it works, if ACPI implementation is standard conform; admittedly a rare case. There are all these quirks, which Linux has to work around often without disclosure from the manufacturer.

        My previous ThinkPad X220, T480s worked, and the current X1 Carbon G10 works, without any issues. Better than Microsoft own Surface Pro company laptop.

    • Re:Sounds like splitting hairs to me? (Score:4, Interesting)

      by Big Hairy Gorilla ( 9839972 ) on Sunday January 26, 2025 @03:14PM (#65120121)
      Systemd users have to put up with all manner of indignities, like Windows users.
      Proper power handling isn't really something you can overlook today.

      Systemd will wait for 1 minute 30 seconds for who-the-fuck-knows-what, frequently.
      After that times out, it might wait for other processes to shut down, for another 1 minute 30 seconds. Rinse and repeat.

      My Devuan laptops shut down in the blink of an eye, boot to login prompt in under 4 seconds... and suspend to RAM and wake reliably, and fast enough, i.e. very fast, <2 seconds, that you don't pay any attention, on all my the laptops I use or support, Dell, and Asus.

      If suspend isn't working, it's probably a hardware incompatibility.

      tl;dr, don't use systemd. if your software is dependent on it, consider better software. Also consider a better OS (one that doesn't use systemd)

      • Systemd will wait for 1 minute 30 seconds for who-the-fuck-knows-what, frequently.
        After that times out, it might wait for other processes to shut down, for another 1 minute 30 seconds. Rinse and repeat.

        That used to piss me off so badly. There was a service that did nothing but wait that long to see if an ethernet card obtained a link. Yeah that was really fun on a machine with dual ethernet ports on the mobo plus a quad card. No way to break out of it either during the boot process. I think they finally did away with that service.

        • no that service is still there but you can configure it away by setting your nic to "optional". The service is there due to you having some other service having network as a dependency (ntp, chrony, sshd, ...).

      • Systemd will wait for 1 minute 30 seconds for who-the-fuck-knows-what, frequently.
        After that times out, it might wait for other processes to shut down, for another 1 minute 30 seconds. Rinse and repeat.

        Or, it will Microsoft the Progress Bar, saying it's waiting for 1:30, then when it counts up to 1:30, change the limit to 3:00 and carry on doing this ad infinitum. For fuck's sake, it's a shutdown. Give it 10 seconds, then kill -9 the fucker, then force unmount it. GTFOH.

        • when it does that it's because the service is configured to behave that way, also some services can notify back that they need more time (also something that can be disabled in the config).

          • Thanks, I'll look into configuring that.

            I've done a little casual grepping of unit files and man pages, usually in the heat of annoyance after it does something stupid, not seen an obvious fix, and moved on with some grumbling about Registries and how much better it was in the days of Slackware 7.

            But knowing it can be done might inspire further probing.

            • /etc/systemd/system.conf is where the defaults are set, the uncommented ones show the compiled default value which is 90s for shutdown : #DefaultTimeoutStopSec=90s remove the # and set the value to say 1ms to make the default not waiting more then one millisecond (0 might be invalid value, not sure, never tested) unless for the units that have set this value specifically in their unit file (which should be a very small set of units).
      • that is because it is configured to wait that amount of time, change the default to 0 and you get the same instant shutdown as you get on devuan. Ofc proper waiting is the proper way since there might be services that needs to flush to disk, but then those tends to be more common on servers and not so much on desktops.
        • So where do you make that setting? SVP

          • in /etc/systemd/system.conf in that file you will find a commented line with the compiled default value:

            #DefaultTimeoutStopSec=90s

            Change that to:

            DefaultTimeoutStopSec=1ms

            And do a "systemctl deamon-reload" and close to all services should now terminated immediately, the ones that don't have set their own timeout in their unit file and for those one have to either edit those specific unit files or create override files for them with just a:

            [Service]
            TimeoutStopSec=1ms

            Note that name difference between th

      • Wait- systemd is being blamed because some process is stuck, holding the disk?
        How the fuck are you supposed to be taken seriously when you don't even understand the problem?
        Systemd doesn't wait "1 minute 30 seconds for who-the-fuck-knows-what", period.
        It does as asked- there is a unit file telling it to do that, and the process it's watching there is broken.

        Learn to competently administer your system.
        • ... by using a better one, that doesn't make me jump thru unneccesary hoops.

          shutdown -h now

          I said NOW not 1m, 30s from now.

          Systemd sucks donkey balls, you know it.

          • shutdown -h now

            All that does is trigger init to go through its shutdown process, no more, no less. You can do the same thing with telinit.
            It does the same thing on a systemd system, where systemd is the init.

            init will, in fact, hang even indefinitely depending on the scripts, if something is hanging (we see it all the time on our servers).
            For example, processes in D state can't be kill -9'd, and disks with open file descriptors can't be unmounted, and init will not generally force that (though it can be made to, as ca

    • I love it when I go to leave work, shut down my laptop and be forced to wait for the updates to install before it actually shuts down.

      At least it means I get to wait for it to finish updating when I turn it back on in the morning, and get paid for doing nothing.

  • An average 1980s computer will start faster than you can move your hand from the back of the computer--to reach for your coffee. Still, Linux boots quicker Windows--even though it cheats several ways, such as delayed start, and not even shutting down like it should.

    • I recently installed a Fedora 20 (2014) vm to handle a UPS that needs java applets.

      Amazingly that vm gives me a login screen in about 3 seconds. And that's on a Gen 1 Ryzen 7 and the disk image only on a gigabit iscsi target.

      My Debian 12 machines take a good 15 seconds to boot on a current cheap laptop. It seems like current linux always takes fifteen seconds to boot on current hardware.

      The new ZFS parallel import will help a little bit but sleeps are always a workaround for the real problem unless you are

    • Re: (Score:3)

      by bn-7bc ( 909819 )
      well if you define "An average 1980s computer" as a system that loads its os/basic interpreter from ROM then I'll agrre with you. On anything that involved loading from FDD/HDD your boot time woul priobably be way slower than what tyou said

  • Old and Vague Memories (Score:3)

    by AncalagonTotof ( 1025748 ) on Sunday January 26, 2025 @01:19PM (#65119895)
    I'm not sure : am I correct to say that years ago, it has been stated that ACPI has been rotted by Microsoft (intentionally ?), forcing others to deal with bugs and "correct (on paper) but incorrect (IRL)" specifications ?
    The following, I'm sure of it, I heard it in 2015, during the Microchip Masters Berlin event : Microsoft is part of the companies that define USB. But their implementation is intentionally buggy. Deal with it. Literally. You know how you should write your code, but you can't because of Microsoft.

    Well, that's one way to annoy the competition ...
    • ACPI was rotted by computer manufacturers. Blaming Microsoft is just lazy.
      Frankly, MS main contribution as I see it- WMI calls in ACPI are far superior and less prone to manufacturer fucktastic jank then native ACPI calls (simply because they are, at least to some extent, self-documenting, so you don't need to fucking analyze the ACPI VM code to figure out what each 4-letter-fucking-function-call does)

      I may be slightly traumatized by a decade and a half of implementing laptop ACPI support in linux ;)

Slashdot Top Deals

Just because he's dead is no reason to lay off work.

Close