-
-
Notifications
You must be signed in to change notification settings - Fork 581
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long-running picom causes system slowdown (high CPU usage of Xorg process) #1289
Comments
hmm, this is interesting. i've never seen this myself, so i think you might need to do some investigation yourself. also i am curious why your first instinct is too report issue here, instead of to Xorg? |
Yeah, that was my hunch as well. I'm not really sure where to begin, so if you could give me some initial pointers it would be nice.
Killing picom immediately resolves the stuttering issue and other compositor (read: I'll do some more investigations (not really sure how yet), and report to Xorg if this seems unrelated to picom! |
there are 2 things i can think of:
|
Thanks! I'll try some things once I get back home and report back. |
I've the same problem, I can't solve it |
Alright, here's something I've found. It happened much faster this time. Current uptime is 2 hours and 36 minutes. I've installed the debugging symbols for Xorg (via Anyways, I've done some rudimentary performance analysis:
Same thing, with picom
I noticed a metric tonne of instructions after picom. When picom is running, I see walls of calls to
Not sure where this is coming from. I'll do a quick reboot to see if this is normal behavior. |
Rebooted. Now the issue is gone, so I might need to wait unknown amount of time to reproduce :( Either way, ran I'm really confused. Since Xorg process is the one receiving the signals, so surely Xorg process is the one registered the alarms. For the full log: refer to these files. For all traces, I just focused another terminal and typed random string for several seconds, then pressed
|
You need to |
I don't see anything out of the ordinary so far, can you run |
I haven't been able to reporduce the slowdown yet. I'll report back soon! |
I am getting the same symptoms after upgrading to NixOS 24.05 recently (picom v11). There are two picom processes (or possibly threads) that each use 100% CPU, and also systemd-journald. Looking at the journal, picom is producing millions of log lines like this
I estimate about 50-100 of these per millisecond. Like in the original post, this happens after the computer has been on for some time. Perhaps it has to do with putting the screen in sleep mode. Unlike the OP, this is on Nvidia hardware.
|
I can see that gl_check_err is only called at the end of _gl_compose, near line 487. So it would seem that _gl_compose gets called a lot and that something fails on each call. Not sure that logging every single one of these is very helpful as I now have over ten million such log lines in my journal - perhaps it's better to give up and crash picom. But the root cause is probably elsewhere - something in the GL context or graphics card state changes so that some call in _gl_compose starts failing. |
@RangHo can you confirm what @mattiasflodin has found? |
@yshui Unfortunatly not yet. I've been trying to replicate it a couple times so far, but I haven't been able to. I have volatile syslog setup as well, so I don't have previous journals, unfortunately. Will report once reproduced. |
happens to me every day now since I leave my system running. killing picom and restarting it fixes it (until i leave my system idle for a few hours again) |
I'm dealing with this, too. I actually made 'Kill Picom' and 'Start Picom' buttons on my Stream Deck because of how often I have to restart it. Don't have much to add beyond that, though. I'm on Arch Linux running AwesomeWM, an AMD Ryzen 7 5700X, and an AMD Radeon RX 7600. |
if you have this problem it would help if you can do the steps i listed in: #1289 (comment) |
I was just able to reproduce the symptom. It started really early (uptime was ~53 min), and was able to gather some information. I'm having a stronger suspicion that this is a problem in the upstream, though. More about that later. Regarding what @mattiasflodin reported, in my picom log, I do not see anything related to GL errors. There is no severe warnings at all, in fact. Regarding what @m8uz and @ColetteDiskette reported, I also think that is a different issue from this one, as in their case restarting picom seems to solve the issue. In my case, restarting picom just re-introduces the massive CPU lag. This is the screenshot of Xorg is spending most of its time in (I guess this one?) I attached The full, MASSIVE log is here: xtrace.log (it is like 24 megs). By the way, the debug symbols were retrieved from the latest Void Linux packages ( Should I bring this to upstream? Or is this a picom issue? |
@RangHo Thanks! This is very helpful, I will try to investigate a little bit with information but I might need more. @mattiasflodin looks like your issue is unrelated, can you open a new issue for that? thanks. |
Something on your system is creating an enormous number of 1x1 sized windows. picom needs to monitor damage for every window, that's why you are seeing Looks like this is not a picom problem, but I suggest you look into what's creating all these windows. |
Yeah, something (hopefully not picom) created 17384 1x1 windows... That's weird. If you search in the xtrace.log for
If you see |
Holy cow, that is really weird. Since I already restarted the machine and no longer has the issue, I need to wait a while again to reproduce it. I'll try the options you suggested! On the other hand... while this is an issue unrelated to picom, the procedure I've gone through seems like a good starting point into debugging performance issues in Xorg in general. |
Yeah, sure. I am intrigued as well. Hopefully we don't find picom creating those windows because of a bug somewhere... |
@yshui I'll try to see if I can reproduce it while running in xtrace and then report a separate bug. |
I think I figured out what's going on for mine, from a high level at least. When I close a window in AwesomeWM with For each one of these, the CPU usage slowly goes up, and over time I can watch my temperature climb. Over the course of a day it can go up 15 to 20 C from regular computer usage. Killing picom and starting it back up makes things good again. Should I start a separate issue for this, or would this be considered an X or maybe even Awesome issue? I don't understand how these things work at a low enough level to know exactly where this would need to go. |
I was able to reliably reproduce the performance degradation. It was a combination of XMonad's 2024-07-23.11-37-42.mp4As you can see, when the state of the WezTerm window changes (position, hidden/visible, visiting another workspace, even typing on it... anything, really), it generates SHIT TON of these 1x1 windows. The performance degradation is clearly visible. Kitty, on the other hand, does not show this behavior. For now, the workaround is to ditch WezTerm and use something else. It was hard to locate since these 1x1 windows doesn't show any property on I'll bring this to WezTerm and see what they can do about it. I think it is safe to close this issue as well. For other performance degradation cases, I suggest opening separate issues. Thanks @yshui for your help! |
Platform
Void Linux (glibc, x86_64)
GPU, drivers, and screen setup
Framework Laptop 13 AMD, Ryzen 7840U, Radeon 780M.
Environment
XMonad 0.18.0
picom version
Diagnostics
Version: v11
Extensions:
Misc:
(Another compositor is already running)
Drivers (inaccurate):
modesetting
Backend: glx
Backend: egl
Configuration:
For GitHub link: HERE
Configuration file
Steps of reproduction
Expected behavior
Running picom for a long time should not cause any performance degradation.
Current Behavior
Quite significant performance hit. See video below.
2024-07-07.20-35-03.mp4
Other details
As shown in the video above, once the stuttering happens, simply restarting picom does not resolve the issue. When I restart picom, the issue comes back.
I noticed that when I enable picom, the Xorg process takes up an entire core in my machine.
Before:
After:
Thanks in advance!
The text was updated successfully, but these errors were encountered: