|Summary:||Kernel 4.14 causes high cpu usage, 4.12 was OK|
|Product:||xorg||Reporter:||Andrew Randrianasulu <randrik>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
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. hw: 01:00.0 0300: 10de:0606 (rev a2) (prog-if 00 [VGA controller]) aka 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 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.