[Dri-users] Re: [Xpert] X memory usage

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

I sent this to Xpert, and Brian Paul suggested that it would be
interesting here too, so I'm forwarding a couple messages.  Check the
Xpert archives (you can get there from www.xfree86.org, click on
"public mailing lists") for the whole thread.

-andy

----- Forwarded message from Andy Isaacson <ad...@mr...> -----

Date: Thu, 7 Sep 2000 15:12:06 -0500
From: Andy Isaacson <ad...@mr...>
To: xp...@xf...
Subject: Re: [Xpert] X memory usage
Message-ID: <200...@mr...>

On Wed, Sep 06, 2000 at 04:23:04PM -0700, Mark Vojkovich wrote:
> On Wed, 6 Sep 2000, Kiril Vidimce wrote:
> > Hi,
> > 
> > What kind of memory usage for the X server would be considered as "normal"?
> > My X server uses at least 286 MB of RAM (most of it resident) even after
> > a fresh reboot. 
> 
>   Physical memory usage of a freshly booted server is at most a few
> meg.  Unfortunately, it's difficult to determine what the physical
> memory usage of the server is, which is why I believe the number you
> are quoting to be completely bogus.  "Top", for instance, does not 
> report physical memory usage.

[I'm beginning to sound like a broken record to myself, but there seem
 to have been a lot of new people joining the list recently, so here's
 one more advertisement.]

Ah, but with a little brainwork you can find out where all that
memory's going using my handy pmap utility.  Grab it from
http://web.mr-happy.com/~adi/pmap.c
then compile it and run
pmap `pidof X`
or
pmap `pidof XFree86`

and you'll get a nicely formatted map showing you what memory your X
server is using.  Here's a example, from a Matrox II PCI not using DRI:

/opt/XFree86/bin/X(232)
08048000 (1260 KB)   r-xp (08:06 201038)   /usr/local/opt/XFree86/bin/XFree86
08183000 (180 KB)    rw-p (08:06 201038)   /usr/local/opt/XFree86/bin/XFree86
081b0000 (3984 KB)   rwxp (00:00 0)      
40000000 (72 KB)     r-xp (08:01 8494)   /lib/ld-2.1.2.so
40012000 (4 KB)      rw-p (08:01 8494)   /lib/ld-2.1.2.so
40013000 (4 KB)      rwxp (00:00 0)      
40014000 (16 KB)     rw-s (08:01 8523)   /dev/mem
40019000 (112 KB)    r-xp (08:01 8812)   /lib/libm-2.1.2.so
40035000 (4 KB)      rw-p (08:01 8812)   /lib/libm-2.1.2.so
40036000 (8 KB)      r-xp (08:01 8811)   /lib/libdl-2.1.2.so
40038000 (8 KB)      rw-p (08:01 8811)   /lib/libdl-2.1.2.so
4003a000 (848 KB)    r-xp (08:01 8806)   /lib/libc-2.1.2.so
4010e000 (16 KB)     rw-p (08:01 8806)   /lib/libc-2.1.2.so
40112000 (16 KB)     rw-p (00:00 0)      
40116000 (4096 KB)   rw-s (08:01 8523)   /dev/mem
40516000 (8192 KB)   rw-s (08:01 8523)   /dev/mem
40d16000 (64 KB)     rw-s (08:01 8523)   /dev/mem
40d26000 (176 KB)    rw-p (00:00 0)      
40d58000 (3308 KB)   rw-p (00:00 0)      
bfff2000 (56 KB)     rwxp (00:00 0)      
mapped:   22424 KB writable/private: 7756 KB shared: 12368 KB

The first two segments are the binary; the next is the heap
(probably), then some libraries and other miscellaneous mappings, then
the several large /dev/mem mappings are the device registers and frame
buffer.

The interesting number for measuring impact on available physical
memory is the last line, "7756 KB writable/private".  Although "top"
claims that X is taking up 20MB with a RSS of 16MB, in fact there's
only 8MB of physical memory allocated (approximately).  (I'm pretty
sure top counts device mappings as part of RSS.)

I'm leaving out a bunch of nuance here, but that's the gist of the
matter.  It's also interesting to explore how programs that look big
(like xterm) actually are mostly using shared mappings.

-andy
-- 
Andy Isaacson <ad...@mr...> http://web.mr-happy.com/~adi/
I want to buy your broken laptop! http://web.mr-happy.com/~adi/laptop.html

----- End forwarded message -----
----- Forwarded message from Andy Isaacson <ad...@mr...> -----

Date: Thu, 7 Sep 2000 17:21:16 -0500
From: Andy Isaacson <ad...@mr...>
To: Kiril Vidimce <vk...@pi...>
Cc: xpert@XFree86.Org
Subject: Re: [Xpert] X memory usage
Message-ID: <200...@mr...>

On Thu, Sep 07, 2000 at 03:00:02PM -0700, Kiril Vidimce wrote:
> Hi Andy,
> 
> I grabbed your utility (pretty useful) and here is the output:

Much of this is similar to mine, but I'll point out a few interesting
points -- looks like you're using the nvidia driver (the binary
module).

> /usr/bin/X11/X(1552)
[snip]
> 44310000 (64 KB)     rw-s (08:01 212269)   /dev/mem
> 44320000 (65536 KB)  rw-s (08:01 214025)   /dev/nvidia0
> 48320000 (64 KB)     rw-s (08:01 214025)   /dev/nvidia0
> 48330000 (128 KB)    rw-s (08:01 214025)   /dev/nvidia0
> 48350000 (8192 KB)   rwxs (00:00 0)      
> 48b50000 (16384 KB)  rw-s (08:01 214025)   /dev/nvidia0
> 49b50000 (65536 KB)  rw-s (08:01 214025)   /dev/nvidia0
> 4db50000 (8192 KB)   rwxs (00:00 0)      
> 4e350000 (65536 KB)  rw-s (08:01 214025)   /dev/nvidia0

These are the device mappings.  Looks like a total of over 208 MB of
mappings that are not backed by RAM.

> 525f3000 (64 KB)     rwxs (00:00 0)      
[snip 18 lines]
> 52723000 (64 KB)     rwxs (00:00 0)      
> 52733000 (64 KB)     rwxs (00:00 0)      

Dunno what this is, but it totals under a meg so I wouldn't worry
about it unless you're a developer and want to fix it.

> 52743000 (616 KB)    rw-p (00:00 0)      
> bffe8000 (96 KB)     rwxp (00:00 0)      
> mapped:   313776 KB writable/private: 10932 KB shared: 298652 KB
> 
> I guess this suggests that X is really using only 10 MB and everything
> else is just a mapping to the frame buffer?

Well, "that's a difficult question to answer".  That's a reasonable
starting estimate.  Another reasonable estimate is to take the total
mappings and subtract the devices, which gives something like 98 MB.
The correct answer is probably somewhere in between.  Of course it
also depends on whether the process ever accesses the pages it has
mapped -- if they're not touched, they'll never be read from the disk.

Another take on it is to take the number that "top" reports as the
RSS, then subtract the device mappings.  In fact, it looks to me like
the newest version of top already does this -- I have procps version
2.0.6 (debian package version 2.0.6-9) installed on my bleeding-edge
machine and it says

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
  342 root       9   0 44672 3252  1464 S       0  0.0  1.2   2:51 X

while the version of top in procps 1.2.7-1 when run on the same system
reports

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
  342 root       9   0 44672  43M  1464 S       0  0.0 17.3   2:51 X

So, I suppose the real quick answer is "upgrade your procps package!"

-andy
-- 
Andy Isaacson <ad...@mr...> http://web.mr-happy.com/~adi/
I want to buy your broken laptop! http://web.mr-happy.com/~adi/laptop.html