Compiz flashback has high-CPU kworker thread when screen updates

Bug #1744515 reported by Misaki
This bug affects 1 person
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)

Bug Description

When the screen updates, there is one or two kworker threads with high CPU. This is 30~40% of a CPU as shown in top, on my old system with two CPU cores.

This did not happen in 16.10. I recently upgraded a badly out-of-date 16.10 to 17.04 and then immediately to 17.10, so I don't know when it showed up.

Examples of when it happens is when a video player like ffplay is running, even if it's just showing something very simple like the sound frequencies in a music file, or when I scroll up and down in this browser window. The size of the window is unimportant; the same kworker activity is shown whether the window is maximized or reduced to a small width and zero height. It goes away if the window is minimized.

It doesn't happen in Metacity flashback, in "Ubuntu with Xorg", or with "Gnome with Xorg" from the login screen. For some reason I have duplicates of those last two options, that differ in that one of them has a blank circle for the icon. What are presumably the Wayland options don't let me login — if I try to select them, there's a white outline and the previous option stays selected with a filled background, and the selection menu stays there until I select an Xorg-based option. So I can't test those. '"Ubuntu with Xorg" and "Gnome with Xorg" did show gnome-shell with ~15% CPU usage of a core, which is probably unnecessary but completely unrelated to this bug.

Metacity flashback in 17.10 showed the CPU usages I experienced in 16.10 with Compiz flashback, which is about 10% of total CPU from user and system while playing an audio file with frequency display in ffplay. This bug brings system CPU as shown in 'top' to 25%.

If it helps, the active kworker thread seems to always be named 'kworker/u4:number', usually the same one or two threads.

I tried enabling or disabling some compiz options related to screen drawing, but it didn't seem to do anything. I didn't disable the 'Composite' or 'OpenGL' plugins as they were required by too many others.

This is filed under compiz because no other window manager leads to the problem, even though it isn't the compiz process with high CPU.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: compiz 1:
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64

ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,imgpng,regex,gnomecompat,place,move,vpswitch,mousepoll,obs,wall,animation,shift,snap,resize,expo,session,ezoom,workarounds,staticswitcher,fade]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: GNOME-Flashback:GNOME
Date: Sat Jan 20 16:04:52 2018
DistUpgraded: 2018-01-08 23:06:14,204 DEBUG Running PostInstallScript: './'
DistroCodename: artful
DistroVariant: ubuntu
 NVIDIA Corporation G96M [GeForce 9650M GT] [10de:064c] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. G96M [GeForce 9650M GT] [1043:1912]
 b'org.compiz.core' b'outputs' b"['1024x768+0+0', '1024x768+0+0']"
 b'org.compiz.core' b'hsize' b'2'
 b'org.compiz.core' b'active-plugins' b"['core', 'composite', 'opengl', 'compiztoolbox', 'showrepaint', 'imgjpeg', 'decor', 'imgpng', 'regex', 'gnomecompat', 'place', 'move', 'mousepoll', 'obs', 'ezoom', 'workarounds', 'dbus', 'text', 'wall', 'snap', 'resize', 'staticswitcher', 'session', 'fade', 'bench']"
 b'org.compiz.core' b'vsize' b'2'
 b'org.compiz.core' b'lower-window-button' b"'Disabled'"
MachineType: ASUSTeK Computer Inc. N50Vn
PackageArchitecture: all
ProcKernelCmdLine: root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash
SourcePackage: compiz
UpgradeStatus: Upgraded to artful on 2018-01-09 (11 days ago) 03/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.asset.tag: ATN12345678901234567 N50Vn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0: N50Vn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:
version.libdrm2: libdrm2 2.4.83-1
version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.4-0ubuntu1~17.10.2
version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.4-0ubuntu1~17.10.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.5-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.10.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20170309-0ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2
xserver.bootTime: Sat Jan 20 15:45:37 2018
xserver.configfile: default
 Failed to load module "nvidia" (module does not exist, 0)
 Failed to load module "nvidia" (module does not exist, 0)
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.19.5-0ubuntu2
xserver.video_driver: nouveau

Revision history for this message
Misaki (myjunkmail311006) wrote :
Revision history for this message
Misaki (myjunkmail311006) wrote :

This also affects the 'Unity' login option, which uses compiz.

Revision history for this message
Misaki (myjunkmail311006) wrote :

The 'Show Repaint' plugin in compiz showed that most of the screen was not getting repainted. Disabling 'Framebuffer object' under OpenGL, in ccsm (CompizConfig Settings Manager), caused the whole screen to be repainted but CPU usage of compiz stayed the same. If Workarounds > 'Force full screen redraws (buffer swap) on repaint' was enabled, CPU usage without Framebuffer object was the same, but with both on, CPU usage of compiz was ~3% higher (from 13% to 16% with CPUs at lowest frequency).

Kworker CPU usage doesn't seem to change when I switch CPUs from 1/3 frequency, to maximum frequency. Compiz drops about 1/3 when I do so (instead of 2/3). On highest frequency, the problem kworker thread uses three times the CPU of compiz.

kworker CPU usage seems proportional to the frames-per-second recorded in the Benchmark plugin. When the ffplay window is reduced to 1 pixel height, so it shows only a constant blue line for audio frequencies, the Benchmark still shows ~55 fps. Toggling on or off the benchmark makes it fade with high fps (from 60 fps), which shows same high kworker usage.

(Metacity has screen tearing.)

Revision history for this message
Misaki (myjunkmail311006) wrote :

Problem does not happen when booting from linux kernel 4.8.0-34-generic; CPU usage is slightly higher than Metacity, no significant kworker threads.

It does happen with updated kernel 4.13.0-25-generic (previously -21). When I went to recovery mode for 4.13.0-25, tried to select failsafeX graphics, then resumed normal boot, resolution was messed up and Compiz and Xorg were at 50~60% of a CPU instead of 5~8%. Unfortunately, did not note whether there was a high kworker thread.

Hope this helps. I don't have any other kernels installed.

Could someone please at least try to verify this? If they don't experience it, that's useful to know as well.

Revision history for this message
Misaki (myjunkmail311006) wrote :

Confirmed to not be (just) a compiz bug because it also affects Wayland, which doesn't use compiz. Using Bionic beta with kernel 4.15.0-15-generic.

This bug filed for Linux package, when I wasn't sure which project was responsible:

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers