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 |
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 | |
We also thank MIT for the use of their facilities. |