Ok, I’m going somewhere here. Two things have popped up while investigating this route.
I thought I had a pretty good grip on how the CPU governor behaves on this machine, but I was wrong. So, it should be using the schedutil governor by default. It’s the governor dictated by the amd-pstate driver from what I understand. Thing is, it doesn’t, and I hadn’t noticed because I only happened to check when I had switched governors manually (using CoreCtl). According to CoreCtl it defaults to the performance governor, but if you really check it out with garuda-inxi it uses the powersave governor on battery. If I switch to schedutil it works, but it reverts upon reboot. That said, the problem with sluggish app opening does get better with the correct governor, but not completely resolved. I have a hunch that this behavior is caused by a Gnome extension for automatic power profile switching when on battery/plugged in, which would make for an easy “fix”. Thing is, I’d prefer to keep this functionality, so a better solution would be to have the machine use the powersave governor with the powersave profile, performance governor with the performance profile and schedutil governor with the balanced profile. Otherwise, it’s way better to nuke that config and stick to the schedutil governor for everything and switch manually only when needed. I’ll also have to check whether CoreCtl is causing any of these problems, but I don’t really know how apart from removing it completely and checking again.
The CPU doesn’t idle properly. I had never bothered to check that and thought that 1400Mhz was fine. It’s not. CPUs from the same family should drop cores to near 0 when not in use (usually reporting something like 400MHz IIRC) and then boost aggresively when in use. I’m not quite sure that this is related, but also the SoC portion of the CPU seems to be drawing 2.5-3W constantly, regardless of load, but it should be dropping on idle along with the rest of the CPU (it does on Windows, I’m pretty sure). Having the extra flag for enabling the pstate driver in grub.cfg doesn’t seem to make any difference at all, so I’d appreciate some pointers as to how I can proceed with that.
Seems like we’re getting somewhere! This honestly gets me kind of excited, especially problem no.2, because I’m already getting amazing battery life compared to Windows. If I can fix that issue and have it idle even deeper it’ll mean even better battery life in practice. So yeah, any help can mean a lot at this point!
EDIT : Changed my avatar to the Tux one I use on most other forums I’m in. It was a disgrace not using a Tux avatar in a Linux forum when I use it in most others and I apologize for that. Forgive me!
The scaling driver prints out acpi_cpufreq, which, if I’m not mistaken, is correct. However, checking the amd_pstate status gives the following result.
[bat error]: '/sys/devices/system/cpu/amd_pstate/status': No such file or directory (os error 2)
Now that is strange. Shouldn’t the amd_pstate driver be there by default?
Damn, even forums need to have complicated syntax when you’re using Arch.
Well, at least we’re getting somewhere with this mess.
So, I tried both Xanmod and tt. No change, I get the exact same behavior. I also flagged “amd_pstate=active” in grub.cfg and that changed nothing either. So for some reason the amd pstate driver isn’t getting enabled. That could definitely play a big part in this situation. Any further suggestions? I’m now officially out of my depth.
EDIT : I’m reading around the web and all I’m finding is older posts about it, so I don’t know if anything’s changed, but I think that the 2020 Zephyrus G14 doesn’t have CPPC support in the BIOS (which I think is required for the amd pstate driver to work) and Asus never bothered to change that because Asus. What’s certain is that there’s no option for it in the BIOS, which is very limited anyway, even in its advanced configuration. If that is the case I’m gonna be pretty bummed and inclined to never buy Asus again, even though I love their hardware.
Yeah, I don’t know man. At this point I’m starting to think it’s Gnome’s fault and because of my false expectations. Maybe KDE is inherrently much snappier than Gnome? I haven’t used Gnome since the days when you could use Compiz to make your closed windows fly away like a paper plane.
As for the scaling driver, the more I think about it, I don’t think it will make a big difference, if any, to system responsiveness. It shouldn’t, really. What it could do, however, is make the thing more efficient without losing performance. I mean, the boosting behavior is as it should anyway, it shoots up to 4.4GHz like it should, that’s not gonna change. But yeah, more efficiency would be nice.
So it’s not just me. Ok, at its worst (so when the powersave governor was also forced) it would take like 5 seconds sometimes, but as it is now it takes 2-3 seconds to open these same apps. The difference in CPU shouldn’t be anything dramatic. Mine is higher end, yes, but yours is Zen 3, so I guess for single threaded everyday tasks they should be pretty much the same. We aren’t talking about heavy massively multithreaded workloads here.
Right now I’m contemplating using preload. Maybe if that can keep the right apps (my most used ones) cached in memory it would make the system snappy enough. I’ll probably give it a go.
EDIT : I tried all sorts of stuff and the amd pstate driver seems to be completely missing. Among others I tried blacklisting the acpi_cpufreq driver and that worked, it disappeared, but it loaded nothing in its place. I tried modprobing the amd_pstate driver and it returned a message saying that there’s no such module in the kernel (that’s on 3 different kernels mind you, Zen, Xanmod and znver2). I also tried enabling pstate shared memory but that changed nothing either. Seems like it’s impossible to get it to work without explicit CPPC support from the BIOS. FFS Asus, get your sh!t together.
Yeah, it’s not like it’s unbearable as is. When it’s using the schedutil or ondemand governors it’s fine. It’s just frustrating when it’s inconsistent. Some apps will open instantly, others will take their sweet time. Oh well, could be worse, could be stuck using only Windows.
Also, these new AMD CPUs are amazing. I have a 5900X in my desktop and it chews through everything even though it’s not the latest and greatest, and it absolutely curbstomps a friend’s 10900K. That said, another friend has bought a new PC with a 7800X3D in it. I don’t know what it is, but that system is so snappy I couldn’t believe it. Makes my PC look like a slouch. Even on his bloated Windows 11 installed, you click on something and it’s open instantly, like, by the time you “unclick” the mouse the app is open. Mine’s fast too, but nothing like that. Makes me excited. I’m probably skipping Zen 4 because finances are tight right now, but when things improve I’m for sure upgrading. I am especially interested in AMD’s rumored high end laptop APUs that have hybrid Zen 5 CPUs and big integrated GPUs (rumors say 40CUs of RDNA 3.5, for comparison their highest end 7900XTX has 96 CUs). These would make killer Linux laptops methinks.
Oh yeah, right, I had forgotten about that. The 5500U and 5700U are “Zen 2+” or straight up Zen 2 and it’s the 5600U and 5800U that are Zen 3. So yeah, I’m a bit higher end, but it still shouldn’t really matter for day to day tasks. I’m quite sure these delays are software related, as KDE on the same machine did everything instantly. Too bad I prefer Gnome on the small screen and with the touchpad. I mean, I could probably make KDE do the same things, but I want to give Gnome another chance after all these years.