Bug 103897 - Kernel 4.14 causes high cpu usage, 4.12 was OK
Summary: Kernel 4.14 causes high cpu usage, 4.12 was OK
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
Depends on:
Reported: 2017-11-24 23:07 UTC by Andrew Randrianasulu
Modified: 2019-12-04 09:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

X log (26.83 KB, text/plain)
2017-11-24 23:07 UTC, Andrew Randrianasulu
no flags Details
dmesg (47.76 KB, text/plain)
2017-11-24 23:08 UTC, Andrew Randrianasulu
no flags Details
opreport (41.37 KB, text/plain)
2017-11-24 23:09 UTC, Andrew Randrianasulu
no flags Details
kernel's config.gz (47.28 KB, application/octet-stream)
2017-11-24 23:09 UTC, Andrew Randrianasulu
no flags Details

Description Andrew Randrianasulu 2017-11-24 23:07:29 UTC
Hello. After upgrading my kernel to 4.14 I noticed strange behavior: If I load X (KDE 3.5.10 session with built-in compositor [kompmgr], self-compiled with many patches, X server 1.19.5, nouveau DDX git) and start to use seamonkey 2.49 (again, self-compiled with gtk2 toolkit, not default gtk3) - after some hours of use X started to eat a lot of CPU time, new windows appear after delay, glxgears slow down to 11 fps or so from default 60. If I restart X session - everything back to normal, for few hours. If I quit seamonkey - CPU usage drops. But if I start it up again - CPU load returns quickly, and not go down until X restart.

Seamonkey use hw compositing (force-enabled) and multiprocess experimental option. Problem is, exactly same seamonkey with same set of tabs work fine on 4.12.0 kernel!

I set architecture to ia32, even if kernel compiled for x86_64 , because all my userspace is 32-bit.

01:00.0 0300: 10de:0606 (rev a2) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GS] (rev a2) (prog-if 00 [VGA controller])

X log, dmesg, opreport data will follow.
Comment 1 Andrew Randrianasulu 2017-11-24 23:07:59 UTC
Created attachment 135703 [details]
X log
Comment 2 Andrew Randrianasulu 2017-11-24 23:08:36 UTC
Created attachment 135704 [details]
Comment 3 Andrew Randrianasulu 2017-11-24 23:09:02 UTC
Created attachment 135705 [details]
Comment 4 Andrew Randrianasulu 2017-11-24 23:09:50 UTC
Created attachment 135706 [details]
kernel's config.gz
Comment 5 Andrew Randrianasulu 2017-11-25 12:00:56 UTC
It seems setting option DRI to "2" instead of "3" workarounds this problem.
Comment 6 Andrew Randrianasulu 2017-12-28 22:44:31 UTC
Bug still here on 4.14.9-x64.

But it seems if I use "xset dpms force standby" X also doesn't eat CPU anymore. If X enters such state by default after some time of user inactivity - it also don't eat CPU time. Unfortunately, I can't do anything useful wih seamonkey if my screen is off.
Comment 7 Andrew Randrianasulu 2018-02-15 07:27:38 UTC
This bug still around for me with 4.15.0
Comment 8 Martin Peres 2019-12-04 09:33:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.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.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/385.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.