Screen updating with vsync enabled causes high-CPU kworker thread in recent kernels

Bug #1744543 reported by Misaki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Originally filed under compiz: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Testing indicates it affects Wayland as well.

The automatically-included information for this reports notes that I'm using kernel 4.8, where this issue doesn't occur.

When the screen updates in recent versions of the Linux kernel, including 4.13 and 4.15 while running Compiz or Wayland, it causes high CPU usage in a kworker thread. This was 30~40% of a CPU core on my system with 4.13 kernel, and is 65% with 4.15. This doesn't happen with Metacity or non-Wayland Gnome. Since Unity uses Compiz, it happens there as well.

This seems unrelated to how much of the screen is being repainted, as the 'Show Repaint' plugin in Compiz can show that only a few pixels are being updated and the kworker load is the same.

Updated test results, having upgraded to Bionic Beaver 18.04, with kernel 4.15.0-15-generic,

-my Flashback compiz login no longer works, it just crashes back to the login screen, so I can't test it.
-Unity uses compiz and still works for me, and still has this bug.
-Wayland has this bug and doesn't use compiz.

Other display managers remain the same. Metacity is the best in terms of not causing the kernel to waste CPU; 'Ubuntu with Gnome' is the second-best, only causing an extra 10~20% of CPU usage from gnome-shell, and no high-CPU kworker threads.

When screen is updating under Wayland, one or two kworker threads use a combined 65% of a CPU core, with gnome-shell using an additional 8% CPU.

This can be trivially triggered by running glxgears, the command 'ffmpeg -filter_complex color=orange:2x2 -f opengl -', or the command 'ffplay dummy -f lavfi -graph color=orange:2x2:60' which all should update a small part of the screen at a tiny CPU cost. For me glxgears uses 1.5%, while ffplay or ffmpeg use 7~12% to create a 2x2 pixel video, but all three programs cause an extra 65% CPU use from the kernel.

My laptop's battery is completely dead so I have to keep it plugged in all the time, but this should be a concern to anyone with a laptop as it will affect battery life.

The 18.04 kernel is not one for which bugs can be filed at kernel.org: https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html

I already confirmed the bug upstream, I assume from Debian; can someone who can replicate this bug test the latest -rc kernel from kernel.org?

NEW DATA POINT! I followed the instructions here to stop screen tearing in Metacity: http://dan.bodar.com/2018/02/26/stop-screen-tearing-on-ubuntu-by-changing-compositor/

However, after testing for this bug with compton running, I found that the bug does occur. Seeing 55% CPU from kworker. If I kill compton while glxgears is running, the kworker thread immediately disappears from 'top'.

I'm guessing the kernel is trying too hard to match screen vsync (vertical sync).

The command in the link is 'compton --backend glx --paint-on-overlay --vsync opengl-swc'. Leaving out '--backend glx' both stops the high CPU use from kworker and causes screen tearing, as shown by https://www.youtube.com/watch?v=5xkNy9gfKOg.

Screen tearing exists for Gnome+Ubuntu login option, which also does not exhibit this bug. Regarding vsync connection as confirmed, changing bug title accordingly. I can't fix the bug myself though.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-generic 4.13.0.25.26
ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
Uname: Linux 4.8.0-34-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0p: misaki 1685 F...m pulseaudio
 /dev/snd/controlC0: misaki 1685 F.... pulseaudio
CurrentDesktop: GNOME-Flashback:GNOME
Date: Sun Jan 21 00:17:16 2018
HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
MachineType: ASUSTeK Computer Inc. N50Vn
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.8.0-34-generic N/A
 linux-backports-modules-4.8.0-34-generic N/A
 linux-firmware 1.169.1
SourcePackage: linux
UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
WpaSupplicantLog:

dmi.bios.date: 03/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: 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:
dmi.product.name: N50Vn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

Revision history for this message
Misaki (myjunkmail311006) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Re: Screen updating with Compiz causes high-CPU kworker thread in 4.13 or earlier

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.15 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15-rc9

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Misaki (myjunkmail311006) wrote :

Tested, and if anything the %CPU of kworker threads is even higher, often staying around 65% in 'top'.

An easy way to get the screen to update is to run glxgears, which should run at screen refresh rate with very low CPU usage.

tags: added: kernel-bug-exists-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: battery
description: updated
tags: added: bionic compiz wayland
description: updated
description: updated
summary: - Screen updating with Compiz causes high-CPU kworker thread in 4.13 or
- earlier
+ Screen updating with Compiz or Wayland causes high-CPU kworker thread in
+ recent kernels
tags: added: vsync
description: updated
description: updated
description: updated
summary: - Screen updating with Compiz or Wayland causes high-CPU kworker thread in
+ Screen updating with vsync enabled causes high-CPU kworker thread in
recent kernels
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.