unix RAM usage (Was: Re: OOo background color - Re: [GNHLUG] MerriLUG Nashua, Thur 20 Sep, OpenOffice Styles - for groff fans and real people too)

Jerry Feldman gaf at blu.org
Wed Sep 26 14:03:20 EDT 2007


On Tue, 25 Sep 2007 21:37:35 -0400
"Ben Scott" <dragonhawk at gmail.com> wrote:

> On 9/25/07, Bill McGonigle <bill at bfccomputing.com> wrote:
> > the virtual size is 47M, but the shared and resident sizes rarely
> > change from their combined 8MB ...
> 
>   This is skirting the edge of my understanding, but my understanding
> is that the virtual size is the total of all pages mapped into a
> process's virtual address space.  That can include:
> 
> - pages in main memory ("RAM")
> - pages swapped out to disk
> - mmap'ed files
> - shared libraries
> - IPC shared memory
> - kernel resources
> - hardware I/O
> 
>   So, basically: Here there be dragons.  ;-)

This is generally true. Emacs is a bit of a beast because much of the
work is performed by elisp. Most elisp modules should be precompiled,
but that depends on some other factors. Most programs use the C library
malloc package (even C++), but utilities can also have their own memory
manager. Additionally, TOP and many other utilities are based on time
samples and averages. Utilities, such as VTUNE and Caliper can provide
you with some more accurate statistical data and some nice graphs. 

A linux process has generally 4 segments:
    Test -- Executable code. Generally read-only and can be shared with
other processes. 

      Data.  This is for initialized data. Usually pages are mapped as
copy-on-write. Then, as part of this you have uninitialized data.  No
space is allocated until a page is touched. 

      Heap. The heap is where malloc generally stores its data when
using the brk(2)/sbrk(2) calls. Pages that are mmap(2)'d don't need to
be contiguous. In general the heap can grow and shrink, but most
mallocs don't every shrink the heap. 

      Stack. The stack itself is normally mapped in a similar way to
uninitialized data. As the process uses the stack for return addresses,
process overhead, and automatic variables those pages will be created. 

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20070926/d539fcd2/attachment.bin 


More information about the gnhlug-discuss mailing list