| 2018-01-21 08:27:25 |
Misaki |
bug |
|
|
added bug |
| 2018-01-21 08:30:07 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Confirmed |
|
| 2018-01-22 20:13:25 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2018-01-22 20:13:28 |
Joseph Salisbury |
linux (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2018-01-23 00:37:37 |
Misaki |
tags |
amd64 apport-bug artful |
amd64 apport-bug artful kernel-bug-exists-upstream |
|
| 2018-01-23 00:38:06 |
Misaki |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2018-04-24 04:08:21 |
Misaki |
tags |
amd64 apport-bug artful kernel-bug-exists-upstream |
amd64 apport-bug artful battery kernel-bug-exists-upstream |
|
| 2018-04-24 04:08:32 |
Misaki |
description |
This duplicates the information in https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Filing this to get more exposure.
The automatically-included information for this reports notes that I'm using kernel 4.8, where this issue doesn't occur. I don't have any other kernels to test with.
When the screen updates in 4.13 while running Compiz, it causes high CPU usage in a kworker thread. This was 30~40% of a CPU core on my system. This doesn't happen with other window managers tested, like Metacity, or whatever non-Compiz Gnome and Ubuntu use (gnome-shell maybe, though that 15% CPU load more than Metacity when I checked). Since Unity uses Compiz, it happens there as well as with 'Ubuntu flashback Compiz'.
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.
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. |
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 4.13 while running Compiz, it causes high CPU usage in a kworker thread. This was 30~40% of a CPU core on my system. This doesn't happen with other window managers tested, like Metacity, or whatever non-Compiz Gnome and Ubuntu use (gnome-shell maybe, though that 15% CPU load more than Metacity when I checked). Since Unity uses Compiz, it happens there as well as with 'Ubuntu flashback Compiz'.
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 both cause ~70% CPU use from the kernel and other processes.
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 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?
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. |
|
| 2018-04-24 04:09:46 |
Misaki |
tags |
amd64 apport-bug artful battery kernel-bug-exists-upstream |
amd64 apport-bug artful battery bionic compiz kernel-bug-exists-upstream wayland |
|
| 2018-04-24 04:13:14 |
Misaki |
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 4.13 while running Compiz, it causes high CPU usage in a kworker thread. This was 30~40% of a CPU core on my system. This doesn't happen with other window managers tested, like Metacity, or whatever non-Compiz Gnome and Ubuntu use (gnome-shell maybe, though that 15% CPU load more than Metacity when I checked). Since Unity uses Compiz, it happens there as well as with 'Ubuntu flashback Compiz'.
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 both cause ~70% CPU use from the kernel and other processes.
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 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?
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. |
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 both cause ~70% CPU use from the kernel and other processes.
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 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?
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. |
|
| 2018-04-24 04:16:13 |
Misaki |
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 both cause ~70% CPU use from the kernel and other processes.
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 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?
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. |
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?
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. |
|
| 2018-04-24 04:22:14 |
Misaki |
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 |
|
| 2018-04-24 05:29:28 |
Misaki |
tags |
amd64 apport-bug artful battery bionic compiz kernel-bug-exists-upstream wayland |
amd64 apport-bug artful battery bionic compiz kernel-bug-exists-upstream vsync wayland |
|
| 2018-04-24 05:29:35 |
Misaki |
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?
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. |
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).
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. |
|
| 2018-04-24 05:50:23 |
Misaki |
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).
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. |
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.
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. |
|
| 2018-04-24 05:57:32 |
Misaki |
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.
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. |
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. |
|
| 2018-04-24 05:57:47 |
Misaki |
summary |
Screen updating with Compiz or Wayland causes high-CPU kworker thread in recent kernels |
Screen updating with vsync enabled causes high-CPU kworker thread in recent kernels |
|
