Bug 529721

Summary: Memory leak in KMS
Product: [Fedora] Fedora Reporter: Nenad Mikša <DoDoEntertainment>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: fedora, jrb, mcepl, mcepl, rstrode, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-06 17:03:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Files Ray required none

Description Nenad Mikša 2009-10-19 16:49:09 UTC 
Description of problem:
There is a memory leak somewhere in KMS which does not appear if I disable KMS.

Version-Release number of selected component (if applicable):


How reproducible:

Boot your system with KMS enabled (tested on ATi and Intel graphics cards). Use Okular for half an hour for reading giant PDF file. Top or KSystemGuard will show that cca 100-200 additional MB were allocated. Now close the Okular. The memory is not freed. If you sum the memory usage of all processes displayed by KSystemGuard or top, you'll see that there is cca 200 MB difference to the actual global memory usage. The longer you use the Okular, the more the difference will be. After the difference crosses the 700 MB (in my case), X session will crash, but the memory won't be freed. The same happens if you manually restart the X.

On the other hand, if you replay this scenario without KMS, you'll see that after short usage of Okular, X memory usage goes up by cca 200 MB, but when you close the Okular, the X memory is freed. The same happens if you restart the X.

Note that in KMS environment, X server memory remained low while using Okular, although global system memory usage raised.

So, my conclusion is that some programs, like Okular, use some X server's features that require extensive memory allocation in the mode-setting code. However, in a non-KMS environment, userspace processes (like X) can free that memory after they don't need it anymore, but if that memory is allocated in kernel space, I believe that userspace processes are not allowed to free that memory anymore, and since no one frees it, it leaks.


Additional info:

General discussion about this bug is also here: http://www.phoronix.com/forums/showthread.php?t=19637
Comment 1 Ray Strode [halfline] 2009-10-20 13:55:27 UTC 
Hi,

I'm moving this ticket to the X server component.  Plymouth isn't involved in this bug.

Would you mind installing xrestop and running

xrestop -b > resources.log

while you work?  Then attach resources.log to this bug report once you've seen memory usage go up significantly.

Thanks.

Also useful would be /var/log/Xorg.0.log and /etc/X11/xorg.conf (if applicable)
Comment 2 Nenad Mikša 2009-10-20 21:55:35 UTC 
Created attachment 365436 [details]
Files Ray required

The gzipped tar containts the Xorg.0.log file, xorg.conf file, resources.log after 2 hours of using Okular to read big PDF and after closing that file (memory wasn't freed).

It also contains screenshot of KSystemGuard showing running processes sorted by memory usage. I highlighted the global memory usage as shown by KSysGuard, and I also highlighted the memory usage column so you can see that if you sum the memory usage of these processes, you won't get even near the value shown as the global memory usage.

NOTE: Processes that are not shown in the screenshot don't use more than a 1 MB of memory, and there are cca 30 of them. So you can add cca 30 MB to your sum. Even with it, you'll get cca 350 MB, and global usage is 730 MB. So, where are those 380 MB?

If I let global usage pass 1 GB, X session crashes and restarts, but the memory is not freed. This does not happen in a non-KMS environment.
Comment 3 Nenad Mikša 2009-10-27 16:37:19 UTC 
I've just updated kernel to 2.6.30.9-90

The issue is still not fixed...
Comment 4 Matěj Cepl 2009-11-05 18:39:08 UTC 
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 5 Nenad Mikša 2009-11-06 17:03:25 UTC 
Since I've had problems with downloading the nightly compose, I downloaded the Beta from http://download.fedoraproject.org/pub/fedora/linux/releases/test/12-Beta/Live/i686/F12-Beta-i686-Live-KDE.iso and tried it in a live session.

Fortunately, I was unable to recreate this memory leak, so I conclude that this bug might be solved.

I will close this bug here, and if it reoccurs, I will reopen the ticket with more info.

Thank you for fixing that issue.