Possible memory leak in KMS?

[DoDoENT]

Hello folks!

How can one check the amount of memory kernel has allocated for its needs?

I'm asking because after 2 days uptime on my Fedora, top reports that 1.1 GB of RAM is used, but if I sum the memory usages per process that top reports, I get cca 340 MB. So where has other 760 MB gone? Even if I restart X server, high memory usage remains. The only way to really free the memory is to do a full restart.

I've found out that this mysterious memory usage appears after playing 3D intensive games (like vDrift), or doing some RandR.

I haven't had such problems on Ubuntu nor Fedora while not using KMS (prior suspend was fixed under KMS: see https://bugzilla.redhat.com/show_bug.cgi?id=508466), so I'll disable KMS for this weekend in order to see if I'll get memory leak as well.

In the meantime, please answer my question: How can one check the amount of memory kernel has allocated for its needs? I just want to be sure if it is the kernel related problem prior filing up bug on RedHat bugzilla.

[DoDoENT]

OK I can now confirm that the problem is in the KMS.

After nearly the same time of uptime as in my previous post, but now without KMS there is no mysterious memory usage.

I found out that after long using of Okular (for reading PDFs while learning for exams), memory usage of X server goes up to 300 MB instead of normal 50-100 MB. But, in a non-KMS environment, after closing the Okular, memory is freed, and X memory usage drops to cca 100 MB. After restarting the X server, global memory usage of my system drops to cca 360 MB, which is the same as in the first boot.

On the other hand, if I enable KMS, while using Okular, X doesn't allocate a lot of memory (it stays down to around 50 MB or even less), but the global system memory usage continues to grow in the same amounts as without KMS. The problem is that after closing Okular, this memory is not freed, not even after restart of the X.

So my guess is that some applications, like Okular, use some of X's properties related to mode setting, which in return allocate a lot of memory. The problem is that, when mode setting is not in userspace, this memory cannot be freed by an userspace process. The problem doesn't appear with KMS disabled, as mode setting code is obviously in userspace.

As far as I know, a friend of mine has a similar problem on a Intel graphic card, so my conclusion is that this is not a driver-related problem, or is it?

So, do you have a similar problem on your Fedora installation? Does this problem appear on other KMS-enabled distros (etc. Gentoo)?

Tell your problems here, so X and kernel developers (who are common guests on Phoronix forums) will have easier time finding and fixing the bug.

Later today, or maybe even tomorrow, I'll file a bug report in Fedora's bugzilla.

[llama]

So, do you have a similar problem on your Fedora installation?

I have a somewhat-related problem. Okular uses a lot of X server memory, but it's not freed when exitting okular. I even exitted all other programs completely, and ever restarted fluxbox, but to no avail, Xorg was still using 2.6GB of VM, with 1.9GB of that resident.

I'm using fglrx from Catalyst 9.11, on Ubuntu Karmic AMD64. vid card = 1GB HD4670. I reported this to ATI,
http://ati.cchtml.com/show_bug.cgi?id=1703, although I'm not sure it's driver specific.

gnome-system-monitor has a column for "X server memory". (xrestop can show the same info. I thought there was another one, more like ps than top, that just listed once, but can't remember. It's not xlsclients...) Xorg is using tons of memory even when nothing is supposed to be using much server memory, so sounds like a leak in fglrx, just like the leak you found in KMS.

I'm going to try using evince for a while, and see if that goes better.

http://bugs.kde.org/show_bug.cgi?id=169863 # memory leak in okular/poppler, not X server, so probably not the same thing.

catch-all server-memory leak bug in xorg-server in Ubuntu
https://bugs.launchpad.net/ubuntu/+s...ver/+bug/98783
Other people have definitely found okular was one program that tickled server memory leak bugs.

There's a good thread on the xorg archives, blaming the problem on malloc/free for not actually returning memory to the OS.
http://lists.x.org/archives/xorg/200...er/041324.html
I'm not sure they're right; I thought the point of mmap-backed malloc was to be able to munmap right away on free. Doesn't glibc do this?

The thread ends with nobody proposing to do anything, and apparently just shaking their heads that Okular expected the X server to deal with the use pattern it uses.

[llama]

In the meantime, please answer my question: How can one check the amount of memory kernel has allocated for its needs? I just want to be sure if it is the kernel related problem prior filing up bug on RedHat bugzilla.

That's a freaky downside to KMS. Normally you can at least see the memory usage of the Xorg process, but having potentially-large memory allocation that's not owned by a process is a new one for most setups.

Try
less /proc/meminfo
(or your favourite text file viewer).

Just say no to people who say
cat ... | whatever
when the command they're piping to could just as well take the filename on the command line, or even as a redirect-from. I hate that.

[DoDoENT]

I'm using fglrx from Catalyst 9.11, on Ubuntu Karmic AMD64. vid card = 1GB HD4670. I reported this to ATI,
http://ati.cchtml.com/show_bug.cgi?id=1703, although I'm not sure it's driver specific.

In F12 this was fixed for me (see https://bugzilla.redhat.com/show_bug.cgi?id=529721) and for friend of mine. So this was definitely a bug in KMS or in X. Ubuntu might still have older version of X and KMS, where this issue still isn't fixed. But if you are using fglrx, that's strange, as fglrx doesn't use KMS.

But, as you said, fglrx might have it's own leak. I remember when I used fglrx on Intrepid x64, where X never used less than 500 MB of RAM. Now I'm using F12 with xorg-video-drv-ati and it rarely uses more than 300 MB .