AMD Has A One-Liner To Help Speed Up Linux System Resume Time 23
Michael Larabel, reporting at Phoronix: AMD engineers have been working out many quirks and oddities in system suspend/resume handling to make it more reliable on their hardware particularly around Ryzen laptops. In addition to suspend/resume reliability improvements and suspend-to-idle (s2idle) enhancements, one of their engineers also discovered an easy one-liner as a small step to speeding up system resume time. AMD engineer Basavaraj Natikar realized a missing check in the USB XHCI driver can avoid an extra 120ms delay during system resume time. It's only 120 ms, but it's a broad win given it's for the XHCI driver code and part of their larger effort of improving the AMD Ryzen platform on Linux and this 120ms savings is from altering one line of code.
from altering one line of code (Score:4, Funny)
120ms improvement? That is nothing, I've taken completely broken code and made it work... wait for it... from altering one line of code.
suspend for my AMD system works great (Score:4, Informative)
i just about fell out of my chair.
Suspend has never worked well for me on desktop systems in linux
am650 asus board, ryzen 7 and a Radeon video card.
No problems at all.
Hilariously if i don't do "xset -dpms" and let it sit there, the video goes away (doesn't crash) and I can't get it back.
So suspend works great but suspending the display is busted.
Re:suspend for my AMD system works great (Score:5, Interesting)
What I found interesting was that the previous code was introduced by an Intel engineer, but the implication is that it affects AMD.
Re: (Score:2)
No, the implication is that whoever implemented it didn't follow the XHCI spec.
And it affected every x86 machine with an XHCI-compliant host controller.... which is all of them these days, Intel and AMD included.
Of course, neither Intel's nor AMD's XHCI bridges are anywhere close to what anyone would call compliant, so one can't really place blame. They're both broken as fuck.
Re: (Score:2)
No, the only interesting thing here is assumptions you made based on lack of information. No where does it say that this only affects AMD systems. In fact it's not related to AMD at all. Here's the information you were given:
1. AMD is going through an optimisation program.
2. This program identified a line in a generic system USB XHCI driver which could be optimised.
3. The AMD engineer who identified it for his AMD optimisation program reported that it improves the speed on the AMD system he tested on.
4. You
Re: (Score:2)
The linux side is a collection of workarounds to handle the fact that all motherboard ACPI firmware is a flaming pile of shit finely tuned to the specific installation of Windows and set of drivers they expect their board to run.
There isn't really an AMD or Intel aspect to it.
I haven't had a laptop with AMD in it in about... probably 10 years. An old Samsung. However- it suspended just fine.
My 2 more recent Intel l
Re: (Score:2)
Re: suspend for my AMD system works great (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
One of the reason I went back to Intel for desktop (Score:2)
Old AMD system there was no working suspend, just power down then boot the next morning. (it would suspend then hard crash on resume).
All our saved seconds... slashdotted (Score:1)
Okay, is that line ... ? (Score:5, Insightful)
AMD Has A One-Liner To Help Speed Up Linux System Resume Time
Re: (Score:1)
AMD Has A One-Liner To Help Speed Up Linux System Resume Time
I'm gonna save...like...$25 per year by suspending my laptop every night and having 5-10 minutes of frustration every morning while I wake it back up and deal with annoying issues...while I lose $25/hr whenever I'm waiting for my laptop to boot so I can "clock in". Totally worth it.
Better than nothing! (Score:5, Interesting)
Hey, it's only 120ms, but... Yay! It's funny, I just built a new AMD rig (5600G/A520) running LMDE 5 and the thing *cold boots* in like 4 seconds, but takes more like 30sec to resume from hibernation, though compared to the last linux system I built (years ago), it's a vast improvement, since suspend/resume actually works!
Re: (Score:3)
Resuming from hibernation assumes the system is in the same state as it was before sleeping. On the other hand when you cold boot in 4 seconds you definitely do not have a system in a fully functioning state. There's more things going on in the background while you login that is getting your system up and ready for you. It probably takes close to equally 30 seconds for your system to actually "finish" booting, regardless of when you're actually presented a login screen.
Logging in and showing the desktop has
Re: (Score:2)
Sure, it's gotta restore RAM, CPU busses, etc., to the state they were in, but I'm sure there's unnecessary delays in there somewhere. It doesn't need to take 30 seconds to copy a few gigs of data from the SSD into RAM. The system really is usable and 100% responsive from a cold boot in under 5 seconds. I realize it's still "doing stuff" even after the system is fully interactive. I'm not really complaining, since unless there's an extended power outage, the machine is either on or suspended to ram. I j
Re: (Score:2)
I can't say for certain, but there is a technical reason for it. It's a difference that transcends OSes. All OSes take significantly longer to resume from hibernation than they do booting.
120 milliseconds (Score:2, Flamebait)
Wow, they saved me almost an eye blink's worth of time.
I'm not saying this wasn't a good thing, but it's nothing to brag about. Literally no one will notice any difference at all.
If this was some sort of polling thing happening hundreds of times a second, sure, brag all you want, but this is like spitting off a dock and then puffing your chest out about how much you raised the sea level.
But okay, sure, good job guys. You da bestest!
I have altered the code (Score:3)
Pray I do not alter it any further.