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 | 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:18 am, Stephen Adler wrote:
> Thanks Jerry,
>
> The kernel does allocate more than 2 gigs of memory since I currently
> have 4 gigs of physical memory in my server, and the kernel reports
> that it "sees" 4 gigs of physical memory. I'm wondering if there is
> a difference between memory allocation in user space and memory
> allocation in kernel space. If I remember right, the CPU runs in
> two different modes, a user mode, and a supervisor mode or something
> like that, and the difference is how the CPU addresses memory.
> (These are notions I have buried deep in my memory... and could
> be false.) So perhaps the user space memory limit is different from
> the kernel space memory limit?
There is a difference. An unsigned 32-bit integer can directly address 4GB, 
but the kernel could use a long long. The 32-bit x86 chip uses a segmented 
memory model. (The X86-64 chips use a linear model when they have a 64-bit 
OS). As I mentioned, use space is subject to limits. Remember that the 
compiler and linker lay out a static virtual memory map for each program. 
But, also, remember that malloc(3) is a library function that runs strictly 
in user space. It calls either brk(2), sbrk(2) or mmap(2) to allocate its 
chunks. While I mentioned the heap barriers, other issues in 32-bit systems 
have to do with pointers. A 32-bit pointer can only address a maximum of 
4GB, so in a 32-bit system, that is the most a normally application will 
get because your application cannot address memory above that limit. 
Malloc(3) gets chunks from the OS, maintains a freelist. When you call 
malloc(3), malloc(3) first tries to satisfy the request from its existing 
freelist (which may be segmented itself). 

The kernel can be made to manage more than 4GBs, but your program will not 
be able to access a virtual address higher than 4.+GB. 
-- 
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