nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications (http://www.nvnews.net/vbulletin/showthread.php?t=131423)

artem 04-12-09 05:16 AM

[FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Quote:

Originally Posted by by Thiago Macieira on Thursday, April 02, 2009 @ 17:07
The NVidia binary Open GL libraries are compiled without -fPIC. This means every single process that links to libGL.so on Linux automatically uses 10 MB of non-shared memory, at load time, and there’s nothing we can do about it. This affects every user of the binary drivers, regardless of desktop.

In fact it's true and I've just tested that:
Code:

$ cat test.c
#include <unistd.h>

int main()
{
        sleep(100);
        return 0;
}

gcc -o test -lGL test.c

./test
Code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5413 artem    20  0 19516  14m 3232 S  0.0  0.4  0:00.03 test_gl

14MB of RAM eaten for an application which does nothing.

Is there a way to preserve memory, NVIDIA?

Linuxhippy 04-12-09 12:55 PM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Quote:

The NVidia binary Open GL libraries are compiled without -fPIC. This means every single process that links to libGL.so on Linux automatically uses 10 MB of non-shared memory, at load time, and there’s nothing we can do about it. This affects every user of the binary drivers, regardless of desktop.
Well, thats done because peak performance is what counts - running a single opengl app as fast as possible. As long as customers judge cards only with that in mind, not a lot will change. PIC code on x86 is about ~5-10% slower, I am quite thankful AMD solved the problem with x86_64.

As far as I've seen they also allocate some large buffers.

- Clemens

artem 04-12-09 08:17 PM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
One can always postpone memory allocation, can't he?

xianthax 04-13-09 12:11 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
hate to take this stance because i usually am very much against this line of thought but....10MB? a gig of ram is $15 we're talking 15 cents worth of ram per opengl app, not exactly a big deal, its not like its something tied to every process, the average user isn't going to have many opengl apps open at any given time. i'm pretty hard on systems and i think i top out at 5 or 6 opengl using processes at a time and thats rare.

in computing whether its at the application level or the algorithm level theres always a speed vs memory footprint battle to be fought, one would correctly argue that if your using opengl for something, chances are that performance is at a much high priority than saving 15 cents worth of ram.

artem 04-14-09 07:48 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
1,5% worth of RAM :)

OK, you've convinced me. Right now on my KDE4 desktop there are just four applications using OpenGL:

Code:

for i in /proc/*/maps; do test -n "`grep -i opengl $i`" && ls -l `echo $i | sed 's/maps/exe/'`; done
lrwxrwxrwx 1 0 2009-04-14 18:16 /proc/4277/exe -> /usr/bin/ksmserver
lrwxrwxrwx 1 0 2009-04-14 18:16 /proc/4282/exe -> /usr/bin/knotify4
lrwxrwxrwx 1 0 2009-04-14 18:16 /proc/4283/exe -> /usr/bin/plasma
lrwxrwxrwx 1 0 2009-04-14 18:16 /proc/4314/exe -> /usr/bin/krunner


Adam Warner 04-15-09 04:23 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
The number that really matters is the difference in the resident working sets of the applications. Everything else can be swapped out to disk. Thus you are not wasting 14MB of physical RAM.

Executing
Code:

int main() {while (1);}
while allocating an excessive amount of memory in another process causes the resident physical RAM of the infinite loop to occupy 44kB on my machine (i.e. 11 pages of memory).

Executing the same code with the -lGL library linked in while allocating an excessive amount of memory in another process causes the resident physical RAM of the infinite loop to occupy 216kB (i.e. 54 pages of memory). [42700kB of virtual memory is consumed versus 3644kB without -lGL.]

Thus the physical RAM wasted is 54-11=43 pages of memory (172kB). If the machine has a modest 1GB of RAM this is an overhead of 172k/1000000k (approximately 0.02%).

artem 04-15-09 02:52 PM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Our kernels seem to count RSS value differently - as I've already shown, in my case RSS value is 14MB, not 216KB :) But it doesn't really matter anyway.

Adam Warner 04-15-09 06:05 PM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Quote:

Originally Posted by artem (Post 1983805)
Our kernels seem to count RSS value differently - as I've already shown, in my case RSS value is 14MB, not 216KB :) But it doesn't really matter anyway.

I was indicating approximately how much of the program needs to remain in physical RAM if you are actually short of physical RAM. Until that happens there is little reason to swap out most of the bloat to disk where it will remain wasting a little bit of disk space until the process is terminated.

If you don't have a swap file/partition configured then the bloat will remain resident in physical RAM even if other applications are competing for that RAM. If I execute "swapoff -a" as root the resident footprint of the mostly swapped out infinite loop compiled with -lGL jumps up to 4MB on my machine.

artem 04-16-09 03:00 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
I've been running all my PCs and most servers I administer without SWAP for the last 7 years and I've never had a single problem. I don't know a single reason why someone should have SWAP enabled (having enough RAM for the applications you run, of couse - my working PC has 2GB of RAM and home PC has 4GB of RAM).

8 years ago RAM was too expensive ;)

NvFuchs 04-16-09 04:43 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Quote:

Originally Posted by artem (Post 1984303)
I don't know a single reason why someone should have SWAP enabled

S4. Not all configurations support / not all users want to put this in a file.

Fuchs

artem 04-17-09 01:54 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
If you have more than 2GB of RAM then hibernate is usually intolerably slow :) - for most laptops I've seen, cold boot is faster than resuming from hibernate. Probably that was a glitch on WinXP side (alas, in my country almost no one runs Linux on their laptops - so I cannot really compare the results, I mean XP vs. Linux).

What is your experience, NvFuchs? How does hibernate work for you?

NvFuchs 04-17-09 02:14 AM

Re: [FEATURE REQUEST or BUG REPORT] Excessive RAM usage by OpenGL linked applications
 
Quote:

Originally Posted by artem (Post 1985224)
If you have more than 2GB of RAM then hibernate is usually intolerably slow :) - for most laptops I've seen, cold boot is faster than resuming from hibernate. Probably that was a glitch on WinXP side (alas, in my country almost no one runs Linux on their laptops - so I cannot really compare the results, I mean XP vs. Linux).

What is your experience, NvFuchs? How does hibernate work for you?

With the most recent tux on ice for 2.6.29 it runs fine.
TOI supports compression, puts the CPU on full speed for S4 and now does lots of tasks parallel. Resume takes about as much time as a regular boot, but I still have all my applications open and no data is lost. So there is a slight time gain.

As well my notebook goes to S4 when battery is below 2%.

I am rather happy with it, but I don't use it that much, maybe 2-3 times a month. Usually S3 is enough.

Fuchs


All times are GMT -5. The time now is 08:49 AM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.