You are not logged in.
So using an AMD GPU, sometimes between Arch Linux updates made with pacman -Syu I get some slower opening windows time. It's random, but I'm mostly sure it's because of the updates. I had been experiencing this like months back, but I was able to not experience it in many many weeks, probably months. What I saw with this bug is first when I start my WM with startx, the process to launch the WM is slow, it does take a couple of seconds to get out of the black screen and start to see my WM. After that every new program that I launch is going to take a couple of seconds to load the graphical interface or TUI if for example is a terminal. The most strange thing is that just happen the first time that I launched a program, for example my browser is going to take like 3 or 5 seconds in being loaded to screen, but after that, any new instance of the browser after get it closed, it's going to be launched instantly.
So the issue is: When I start to launch every graphical program thing, not matter if it is GUI or TUI, it's going to load it in the screen in the first time slowly, then everything just works well. It's not like the screen freeze in a moment, I can move the mouse while the program is loading. But is weird because it's not deterministic in some sense at all. I'm not sure if it is just totally random or the update of a package create this, but in some sense it also gets fixed very quickly, which I don't think that's the case.
So anyone here experiencing this kind of issue ? Maybe it's just me and ROCm making brr badly once in a while :C . Sometimes I get this issues, sometimes don't.
Last edited by Succulent of your garden (2025-09-17 21:15:18)
str( @soyg ) == str( @potplant ) btw!
Offline
my browser is going to take like 3 or 5 seconds in being loaded to screen, but after that, any new instance of the browser after get it closed, it's going to be launched instantly
Disk or filesystem, possibly just
between Arch Linux updates made with pacman -Syu I get some slower opening windows time. It's random
just sideload from pending writebacks?
Try to run "sudo sync", how long does that take and does the system perform better afterwards?
nvme/ssd? NAND-flash writes much slower than it reads, notably on worn out devices.
https://wiki.archlinux.org/title/Benchmarking#dd
Offline
I am experiencing something similar also using amdgpu and just found out that my log is full of:
kernel: amdgpu 0000:03:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000013 SMN_C2PMSG_82:0x00000009
kernel: amdgpu 0000:03:00.0: amdgpu: Failed to disable gfxoff!Check yours, if you see similar things, might be the explanation.
Offline
nvme/ssd? NAND-flash writes much slower than it reads, notably on worn out devices.
I don't think is for the age of the drive, it's pretty new to be honest, just a couple of months. Do you think it could be the case ? I mean I guess maybe is not duplex in I/O nature, but hey it's 2025 nvme is very fast than my first 1GB HDD drive in a computer which need to manually be shut down every time
just sideload from pending writebacks?
Do you think that's the case ? I mean could be pending writebacks from previous booting ? I mean my machine went to sleep like 8 hours, then I woke up and boot again.
Try to run "sudo sync", how long does that take and does the system perform better afterwards?
You mean like: I login into my computer, I detect that startx command load the WM in a couple of seconds instead of just mili or nanoseconds, then I just go and open a terminal and do sudo sync ? Then check if browser and other programs launch faster again ?
Check yours, if you see similar things, might be the explanation.
I'm having SMU working fine ^^ , so probably that's not what is causing the problem. But thanks in helping ^^
kernel: amdgpu 0000:03:00.0: amdgpu: SMU is initialized successfully!Last edited by Succulent of your garden (2025-09-17 23:16:48)
str( @soyg ) == str( @potplant ) btw!
Offline
Do you think that's the case ?
I think it's plausible if this only occurs around massive write operations (pacman -Syu updating lots of files) and also
in some sense it also gets fixed very quickly
ie. this is a intermittent condition.
I login into my computer, I detect that startx command load the WM in a couple of seconds instead of just mili or nanoseconds
Yes, but at this point you would not have written anything, right?
The key symptom is that subsequent calls are fast, ie. once it's not the CPU, GPU¹ or any of that but most likely the disk then being sidestepped w/ the FS cache.
¹possibly it's the shader cache?
I'd certainly benchmark file reading writing when things are fast (as a baseline) and then when programs start slow to eliminate every other possible variable.
Read every dd command thrice before you hit enter. It's nicknamed DiskDestroyer for a reason…
If the system is slow to begin with, the issue is going to be sth. else.
Instead of recording what's not there, record what is and post a system journal when the performance breaks down:
sudo journalctl -b | curl -F 'file=@-' 0x0.stOffline
I think it's plausible if this only occurs around massive write operations (pacman -Syu updating lots of files) and also
Yes, but at this point you would not have written anything, right?
Yes, but that's my issue I mean this is my routine:
1) Waking up with a little head pain, need coffee to survive.
2)Mmm go to bathroom, if I feel like shit go to kitchen to make coffee if not turn on the computer.
3)login into computer, startx. Mmmm the startx command today was slow.
4) Open a terminal, seems slow again, do pacman -Syu, press y.
5)If cuda update is in the description, go to kitchen to make coffee.
6)Opening my browser,mmm also slow in opening.
7)Go here to talk with Seth & Jan while drinking coffee.
8)Thinking something like Damn if I'm taking coffe like this probably I'm going to become a Java developer. At least I'm not in the npm hell now ![]()
9)Watch my JS/TS devs friends suffering. Probably that's going to be me someday LoL.
So that's me everyday. As you can see the issue starts before entering pacman -Syu. Maybe it's something related with the FS cache or the shader cache. Do you think considering making the sudo sync command at start if I saw that startx was slow ?
It's nicknamed DiskDestroyer for a reason…
I'm going to /dev/zero my entire system LoL
, but I get the point. I'm going to read carefully.
If the system is slow to begin with, the issue is going to be sth. else.
Which seems the case. I mean the booting is always fine, it always takes the same amount of time, but after session login you can see the slowness.
mmm I'm going to send you a more cleaner journalctl -b when I boot my computer again, because now it's a little dirt with all my programs, I checked some issues when I do sudo virsh net-start default:
This is what happen after virsh net-start default
systemd[1]: Starting Authorization Manager...
polkitd[2845]: Started polkitd version 126
polkitd[2845]: Loading rules from directory /etc/polkit-1/rules.d
polkitd[2845]: Loading rules from directory /run/polkit-1/rules.d
polkitd[2845]: Error opening rules directory: Error opening directory “/run/polkit-1/rules.d”: No such file or directory (g-file-error-quark, 4)
polkitd[2845]: Loading rules from directory /usr/local/share/polkit-1/rules.d
polkitd[2845]: Error opening rules directory: Error opening directory “/usr/local/share/polkit-1/rules.d”: No such file or directory (g-file-error-quark, 4)
polkitd[2845]: Loading rules from directory /usr/share/polkit-1/rules.d
polkitd[2845]: Finished loading, compiling and executing 5 rules
systemd[1]: Started Authorization Manager.But it seems that polkit is just searching for config file until they find one ^^ .
Also I have some containerd complaining, but I don't think that is causing the issue. But for now I also I found this, which maybe could be related to the issue:
(udev-worker)[769]: card0: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/simple-framebuffer.0/drm/card0/device/po>
(udev-worker)[769]: card0-Unknown-1: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/simple-framebuffer.0/drm/card0>
(udev-worker)[769]: card1-DP-2: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card1/card1-DP-2/device/power_d>
(udev-worker)[769]: card1-DP-3: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card1/card1-DP-3/device/power_d>
(udev-worker)[769]: card1-HDMI-A-2: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card1/card1-HDMI-A-2/device>
(udev-worker)[769]: card1-DP-4: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card1/card1-DP-4/device/power_d>
(udev-worker)[769]: card1-Writeback-1: /etc/udev/rules.d/30-amdgpu-high-power.rules:1 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card1/card1-Writeback-1/> What do you think ?
EDIT:
It's weird that my amd card is like card0 and card 1 since it's only one card. I also have the nvidia one, but it seems that the amd one insists in making available the other 3 slots for sound for example. Now I'm currently disabling the sound devices for the card that are available, because I use a separated sound card, it's annoying sometimes because sometimes my main sound card is not detected in the beginning. But that's probably for another post, but I'm saying it to let you know the behavior of my machine.
Last edited by Succulent of your garden (2025-09-18 12:15:32)
str( @soyg ) == str( @potplant ) btw!
Offline
Have you tried the initial login (to a tty) as root, then run pacman -Syu as usual. Whether or not this can show the same slowness would be useful diagnostic info.
If (multiple repetitions) show upgrading on a root-only login is smooth / fast, then I'd try next logging in as your regular user but running the pacman update before startx.
If logging in as root can result in the same problem, then we'd have ruled out all user-related sources of problems.
Last edited by Trilby (2025-09-18 13:00:18)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Have you tried the initial login (to a tty) as root, then run pacman -Syu as usual. Whether or not this can show the same slowness would be useful diagnostic info.
If (multiple repetitions) show upgrading on a root-only login is smooth / fast, then I'd try next logging in as your regular user but running the pacman update before startx.
If logging in as root can result in the same problem, then we'd have ruled out all user-related sources of problems.
I can do that, but why do you think this is a potential good troubleshooting ? I mean I don't think is the pacman -Syu which is creating the issue, is just when I open graphical windows. The slowness starts when I run startx. Seems like xinit suffers a little, don't know why.
Now I was thinking that maybe it could be something related to power saving from the gpu and/or cpu. But not sure, also doesn't seem the case because computers are deterministic in nature, so if it was a power saving thing, maybe this issue would not be random in nature. But by some reason the amd gpu is like: Sorry bro, I'm not going to load the high-power.rules. Go and touch the grass.
str( @soyg ) == str( @potplant ) btw!
Offline
It's weird that my amd card is like card0 and card 1
card0 is the simpledrm device "module_blacklist=simpledrm"
related to power saving from the gpu and/or cpu
The CPU would uptick within fractions of a millisecond and the performance not be related to subsequent starts of the same program.
I mean I don't think is the pacman -Syu which is creating the issue, is just when I open graphical windows. The slowness starts when I run startx.
Which is why you'd run synthetic benchmarks that isolate components.
If dd and eg. bc perform the same it's neither the disk nor the CPU and we'll have to look elsewhere, but if dd breaks in while the system is slow and then later on recovers it'd be pretty safe to say that there's some load on the disk that causes slow disk IO
Offline
Which is why you'd run synthetic benchmarks that isolate components.
If dd and eg. bc perform the same it's neither the disk nor the CPU and we'll have to look elsewhere, but if dd breaks in while the system is slow and then later on recovers it'd be pretty safe to say that there's some load on the disk that causes slow disk IO
I'm going to check it then. But since it's disk destroyer I'm going to take it carefully, I will make it during the week. Now here we are in holidays, so I have time to check it well, and also more rested in the next days. But probably today or tomorrow I'm going to show you my dd commands to be sure that I'm doing the right things ^^
Thanks everyone for the help <3
Last edited by Succulent of your garden (2025-09-18 13:43:22)
str( @soyg ) == str( @potplant ) btw!
Offline
I may have misunderstood - do you see the problem at all when running a pacman update, or are symptoms only seen when moving windows after updating? I was assuming the former - if that's not the case, disregard my suggestions.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
or are symptoms only seen when moving windows after updating?
More like that, but in the beginning of launching programs or WM.
f that's not the case, disregard my suggestions.
It's fine. Thanks for trying in help me <3 ^^
str( @soyg ) == str( @potplant ) btw!
Offline
Today the behavior was different. Same routine as always, startx came quick, not the best time but fine, launch terminal, terminal came fine. Then pacman -Syu and time to do my coffee. Came back, launch the browser, browser launch GUI slow, all other programs also started to do that. since 30 minutes after boot I had run other programs, like LF and my weather script, they launched fast.
This is saying to me that probably this issue is latency from the SSD, as seth told. Going to check dd commands during the following days, today I need a lot to do. But probably this could be solved by trimming the ssd and do sudo sync ?
str( @soyg ) == str( @potplant ) btw!
Offline
Offline
Today I made a pacache and delete all my LLMs that I'm not currently using, which was a lot, but not to much for the size of this ssd.
So from 16% of total space used, now I'm 13%. I trimed the ssd and now it seems that programs are opening as I expected, less than a second ^^
Nevertheless I need to trim the encrypted partition that I have, because with using fstrim -v -a I notice that I'm only triming the boot one, but since it seems I need to put some kernel parameter or something I'm going to do that during the following week, because now I need to do so much in other stuff in my life, sniff.
So I'll be here when I had made the complete triming. Nevertheless thanks anyone here for the help!
Last edited by Succulent of your garden (2025-09-21 11:26:17)
str( @soyg ) == str( @potplant ) btw!
Offline
So I'm planning to do this to do the SSD benchmark, as the arch wiki says:
I'm going to create a test file in my home folder, the one GB file
dd if=/dev/zero of=~/tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progressThis line I have some questions, it is really needed ? I need to runt it as sudo right ? Why this line works ? Why sending a 3 makes that happen ?
echo 3 > /proc/sys/vm/drop_cachesI'm assuming this line is correct, but why in this case tempfile is in the if= of dd ? Most of the time I do writings with putting that in of= instead
dd if=tempfile of=/dev/null bs=1M count=1024 status=progressAnd this is for seeing the buffer cached speed, I get it I must try twice to get the differences in speed.
dd if=tempfile of=/dev/null bs=1M count=1024 status=progressLast edited by Succulent of your garden (2025-10-04 21:25:38)
str( @soyg ) == str( @potplant ) btw!
Offline
This line I have some questions, it is really needed ? I need to runt it as sudo right ? Why this line works ? Why sending a 3 makes that happen ?
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
"sudo echo 3 …" will not work. (Why, what do you need to sudo, what would that sudo?)
https://man.archlinux.org/man/tee.1
I'm assuming this line is correct, but why in this case tempfile is in the if= of dd ?
if = "in file", of = "out file"
You copy zeros into the tempfile, then copy the nirvana - these test different operations? Which?
Offline
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
"sudo echo 3 …" will not work. (Why, what do you need to sudo, what would that sudo?)
https://man.archlinux.org/man/tee.1
Thanks for the info, I read the kernel.org part of drop_caches, and still says the usage of echo "number" > /proc/sys/vm/drop_caches , the file drop_caches is owned by root, so you can edit it without privilege escalation, so I'm assuming that you need to put the tee with sudo in the pipeline or as maybe the kernel.org is trying to say to me: sudo sh -c "echo 3 > /proc/sys/vm/drop_caches
if = "in file", of = "out file"
You copy zeros into the tempfile, then copy the nirvana - these test different operations? Which?
Now everything makes sense, damn thanks very much Seth. I didn't knew that those if and of were acronyms instead of words ![]()
str( @soyg ) == str( @potplant ) btw!
Offline