In general xfwm4 (4.14.0) utilizes 1-2% CPU with composition enabled (htop monitoring. Intel Core2 Duo CPU). But after some time (several times a day) xfwm4 CPU utilization jumping up to 16-20% and stuck at this level. After all windows are closed CPU utilization slowing down to 7-10%. Only after killing and restarting xfwm4, CPU utization goes back to 1-2%.
Which vsync method are you using (glx, xpresent, none) and on which hardware? Can you check with sysprof (or any other profiling tool of your choice) where it spends its cycles when that happen?
Created attachment 8962 screenshot 1
Created attachment 8963 screenshot 2
I use "GeForce 8600M GT" VGA controller with "NVIDIA drivers, 340xx legacy branch (340.107)". It is laptop. There are no info about current vsync method in the driver settings. So I think it is "none". Only in OpenGL tab there is checked "Sync to VBlank" option. I checked with sysprof where it spends its cycles in normal condition (screenshot 1) and when that happen (screenshot 2). It is in file /usr/lib/libgdk-3.so.0.2406.4 (I use latest xorg-server 1.20.5-2 and latest linux 5.2.9)
Ah nvidia proprietary driver, unlikely I'll be able to tell then. The vsync method is not exposed to the UI so no wonder you won't find it there, but anyhow, the nvidia proprietary driver doesn't support Xpresent so that'd be worthless. I am afraid I won't be able to investigate that much further (I don't have have NVidia hardware and no way to tell where in the code it spends its time because no source code is available). So that leaves you with two options: - Turn off glx vsync, but it will tear of course $ xfconf-query -c xfwm4 -v /general/vblank_mode -s off Or - Reproduce the issue with GLX using an Open Source driver
Thanks, Olivier! I was affected by a similar (if more crippling) bug. On my system, having the compositor vblank enabled caused long freezes (15 seconds) when switching between certain windows. For example, switching from Firefox to GNOME Terminal would result in a freeze, but switching between Firefox and GNOME Calculator would not. Also, with monitors of differing refresh rates connected, the freeze would be permanent and I'd need to hard reboot the system (it would become completely nonresponsive; can't switch to TTY, caps lock not working or delayed several seconds, etc). The command you gave actually didn't work for me, so I just opened xfce4-settings-editor and flipped that setting to off myself. Also, restarting xfwm is required for the setting to take effect. I mention this to try to save anyone else the headache of crashing their system an additional time while trying to debug this. I suspect that what's going on is related to my video card. I have a GTX 10-series card that boasts "G Sync," and gaming monitors that are compatible with that feature. The gaming monitors run at 165Hz. I run the proprietary driver, and everything runs pretty smoothly. There's another monitor connected over HDMI, which only supports 60Hz, and I suspect is another source of trouble; having that extra monitor connected is what caused the perma-hang instead of the 15-second freeze. Hope that information is helpful. Happy to provide more. Thanks again!
When I execute "xfconf-query -c xfwm4 -p /general/vblank_mode -s off" xfwm4 stay CPU-friendly, but many apps becomes laggy and unusable. So, I switched on back this option. And also, when i go to nvidia-settings -> OpenGL Settings and uncheck "Sync to VBlank", xfwm4 4.14 utilizes 20-30% CPU all the time just after start, no matter what windows, how many windows are opened.
Created attachment 8992 Screenshot 3
Hi. I confirm this problem with nouveau driver.
Hello, I confirm I have a similar issue with my Intel GPU (Intel Corporation Skylake GT2 [HD Graphics 520]). Sometimes the CPU load is over 90%.
I'm having a somewhat similar issue. In my case, everything works well until I plug in a second monitor. When I plug the external monitor into the VGA port on this machine, if the compositor is turned on, I get 100% CPU load on one of the cpu cores. Top running in a terminal window on the main netbook screen when I do this shows xfwm4 as the process with 100% (+/-) in the "%CPU" column. The system becomes unusably sluggish when this happens. As soon as I unplug the external monitor, overall CPU load goes back to <5% on both cores, and xfwm4 process is using minimal cpu resources. My configuration: $ sudo inxi -G Graphics: Device-1: Intel Mobile 945GSE Express Integrated Graphics driver: i915 v: kernel Display: server: X.Org 1.20.5 driver: intel unloaded: fbdev,modesetting,vesa resolution: 1024x600~60Hz, 1400x1050~60Hz OpenGL: renderer: Mesa DRI Intel 945GME x86/MMX/SSE2 v: 1.4 Mesa 19.2.1 I'll also say that I'm using linux mint, and a similar cpu overload situation occurs if I run a "Cinnamon" session instead of the "XFCE" session. I can select the session from the slick-greeter login screen. In Cinnamon, it's a different process that overloads the CPU, but the same thing happens. Plug in an external monitor on the VGA port and 100% cpu load, unplug it and the load goes away. This does not happen in a Mate session. Turning off the compositor resolved the issue and avoids the cpu overload situation entirely. I was also able to turn compositing back on if I changed vblank mode to "xpresent". It was set to "auto" when I had the issues.
I would need some data as to where xfwm4 is spending its time when the CPU load is high, something like `sysprof` could give a hint.
Oh, and btw, can you try with the modesetting driver instead of intel?
I'm traveling (again), I did install sysprof, and I can gather some data for you with that. I'll also try the modesetting driver. However, I've got both laptops (the netbook with the issue and a full sized Dell laptop), but I didn't bring an external monitor which is what triggers the issue on the netbook. I'll be back home Thursday evening, so I'll do the testing then. Sysprof looks pretty straight forward. You want me to run it and upload the file here, right? What configuration files do I need to change to force the modesetting driver instead of the intel driver? I know I can do that, I'm just not sure what I need to change. I'll probably set up a new "test user" and do my testing from that login, keeping my own login with the workarounds (compositor off or vblank_mode set to "xpresent".
I'm back. I have a sysprof capture file for you, and I'll upload it now. The top lines in teh "functions" side of the sysprof window are: "Everything", 100% in the "total column" (all these numbers are from the "total" column, not the "self" column. Below that, "--kernel--" is at 48.3%, "[xfwm4]" is at 46.49%, and "in file /usr/lib/i386-linux-g nu/dri/i915_dri.so" is at 44.41%, with "43.78%" in the "self" column on that one. So it looks like the dri for the i915 driver is heavily involved here as well. For the capture, I had it just idling, doing nothing for the first 30 seconds or so. At that point, I plugged in the second monitor and the CPU load went up significantly and the thing got very sluggish. The "clock" on the sysprof window was only updating every 6 to 10 seconds. At about 3:30, I unplugged the monitor, and I stopped the capture after 5 minutes. I'll try to figure out how to use the modesetting driver and get back with those results later tonight or maybe tomorrow night.
Created attachment 9400 Screenshot of sysprof Screen capture of sysprof showing results from 5 minute capture with external monitor attached for about 3 minutes during that time. The *.syscap file is 44MB, too large to send here. Even zipped, it's 6.1MB, which is still to big to post here as an attachment.
Created attachment 9401 Short .syscap file from <30 seconds with issue This is a smaller, shorter .syscap file from a 15-30 second run of sysprof while both monitors were plugged in and the system was cpu overloaded and slow and unresponsive.
I finally took a swing at trying the "modesetting" driver. I wasn't sure exactly how to do that, so I finally just removed the 'xserver-xorg-video-intel' package with `sudo apt remove xserver-xorg-video-intel` and did `sudo service restart lightdm`. I get a black screen with a cursor. That's not good. So I went back to the virtual console where I issued the commands (ctrl-alt-F4 in this case) and did `grep '(EE)' /var/log/Xorg.0.log>xserver-errors.txt`. Then I reinstalled the intel driver and restarted again. Here's what's in xserver-errors.txt: ``` (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 9444.262] (EE) Failed to load module "intel" (module does not exist, 0) [ 9444.275] (EE) Failed to load module "intel" (module does not exist, 0) [ 9444.431] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time. [ 9444.431] (EE) [ 9444.432] (EE) AddScreen/ScreenInit failed for driver 0 [ 9444.432] (EE) [ 9444.432] (EE) [ 9444.432] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 9444.432] (EE) [ 9444.467] (EE) Server terminated with error (1). Closing log file. ``` Obviously, I deleted the Intel driver, so we kind of expect the first two errors. After that, the errors seem to be a problem that modesetting had with "glamor," whatever that is. One other observation. The /usr/lib/i386-linux-gnu/dri/i915_dri.so file is being actively maintained/updated. I received an updated `libgl1-mesa-dri` package today, and when I compare the current file to one from my most recent timeshift, here's what I see: ``` $ ls -l /usr/lib/i386-linux-gnu/dri/i915_dri.so /timeshift/snapshots-ondemand/2020-01-29_09-26-22/localhost/usr/lib/i386-linux-gnu/dri/i915_dri.so -rw-r--r-- 5 root root 13274600 Nov 18 13:28 /timeshift/snapshots-ondemand/2020-01-29_09-26-22/localhost/usr/lib/i386-linux-gnu/dri/i915_dri.so -rw-r--r-- 5 root root 13274568 Jan 22 04:57 /usr/lib/i386-linux-gnu/dri/i915_dri.so $ file /usr/lib/i386-linux-gnu/dri/i915_dri.so /timeshift/snapshots-ondemand/2020-01-29_09-26-22/localhost/usr/lib/i386-linux-gnu/dri/i915_dri.so /usr/lib/i386-linux-gnu/dri/i915_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=2cd1b900e09cd7ff82289dbec2c5a48780078496, stripped /timeshift/snapshots-ondemand/2020-01-29_09-26-22/localhost/usr/lib/i386-linux-gnu/dri/i915_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=739cfa5350ebbe97d8db3fda7b534854b6827502, stripped ``` I don't know exactly what changed, but something changed. I won't know until late this week if the change there made any difference for my current issue. Sorry if the formatting is off a bit here. I just copied/pasted most of that from a report on github about this same issue in cinnamon.
> Obviously, I deleted the Intel driver, so we kind of expect the first two errors. After that, the errors > seem to be a problem that modesetting had with "glamor," whatever that is. You do not need to remove the xorg intel driver to use the modesetting driver, you just need to tell Xorg which one to pick, using the appropriate configuration in xorg.conf The message "Failed to load module "intel" (module does not exist, 0)" in your logs indicates that you do have an xorg.conf which is still referring to the intel driver. (please note that all of this is off topic for this issue)
(In reply to Olivier Fourdan from comment #19) > > Obviously, I deleted the Intel driver, so we kind of expect the first two errors. After that, the errors > > seem to be a problem that modesetting had with "glamor," whatever that is. > > You do not need to remove the xorg intel driver to use the modesetting > driver, you just need to tell Xorg which one to pick, using the appropriate > configuration in xorg.conf > > The message "Failed to load module "intel" (module does not exist, 0)" in > your logs indicates that you do have an xorg.conf which is still referring > to the intel driver. > > (please note that all of this is off topic for this issue) Well, excuse me. That was in response to this from you: (In reply to Olivier Fourdan from comment #13) > Oh, and btw, can you try with the modesetting driver instead of intel? I couldn't figure out how to use the modesetting driver with just configuration changes. My system has no xorg.conf file. --- $ find / -name xorg.conf -print /usr/share/doc/xserver-xorg-video-intel/xorg.conf $ --- There are files in the /usr/share/X11/xorg.conf.d/ directory, but none are specifc to the intel driver or the modeset driver. --- $ ls -l /usr/share/X11/xorg.conf.d/ total 20 -rw-r--r-- 1 root root 92 Mar 20 2018 10-amdgpu.conf -rw-r--r-- 1 root root 1350 May 31 2019 10-quirks.conf -rw-r--r-- 1 root root 92 Mar 20 2018 10-radeon.conf -rw-r--r-- 1 root root 945 Apr 11 2018 40-libinput.conf -rw-r--r-- 1 root root 3025 Apr 3 2018 70-wacom.conf $ --- I tried adding a "00-modesetting.conf" file there with options for the modesetting driver to attempt to "force" it to use the modesetting driver, but no matter what I did, it always loaded and used the intel driver. The only way I could make it not use the intel driver was to remove the intel driver, and that's when I got the black screen and noticed the errors in the log, as I pointed out in my last post. As for the info about the i915_dri.so file in the libgl1-mesa-dri package, I included that information because the sysprof indicated that most of the time when it's having the issue, it's "in file /usr/lib/i386-linux-gnu/dri/i915_dri.so" and that file is part of the ligbl1-mesa-dri package. --- $ apt contains /usr/lib/i386-linux-gnu/dri/i915_dri.so libgl1-mesa-dri:i386: /usr/lib/i386-linux-gnu/dri/i915_dri.so --- I thought you might want to know that you're dealing with a "moving target" there.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/344. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev