Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

memory limits....



On Thursday 19 May 2005 11:32 am, markw at mohawksoft.com wrote:

> 32bit code on a pentium or higher is limited to 4G per process.
>
> Way back when, the OS took up the top two gigs, and left the bottom 2G
> for user space. More recently, with larger memory requiements, the OS
> started to give up some of its two gig space back to applications.
>
> A lot of things affect how much space the OS takes up in shared space. It
> is hard to say for sure unless we know more.
>
> If you need much more than 2G in user space, consider 64bit Linux.
When talking about memory that a program can use, one needs to talk about 
virtual space. Virtual space has no relationship to the actual memory that 
is installed. 
For instance, I mentioned that your program is divided up into chunks:
1. Text - this is read only. Your program text segment is mapped to virtual 
memory and is not copied to swap. It's pages are swapped in when needed. 
2. Initialized data. This is generally loaded into memory and copied to 
swap. (The specific strategy depends on the OS's VM and may change between 
releases).
3. Unitialized data. The pages here are created when accessed, and swapped 
to swap space when needed. (This is the bss segment).
4. Stack the stack can be allocated as part of the data areas. 
5. Heap. The classic heap grows (upwards in most systems). This uses the 
brk(2) or sbrk(2) calls. It can stop when it reaches the top of the user's 
virtual map or if something has been allocated above it. 
6. mmaped memory. This is memory you can allocate yourself. You can also 
make this sharable. If malloc(3) fails, you could use mmap(2) and try to 
manage memory yourself.  
-- 
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




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org