Messages in this thread | | | Date | Thu, 6 Jan 2000 15:35:00 -0600 | From | Tim Walberg <> | Subject | Re: Can a process use up more than 910MB? |
| |
On 01/06/2000 18:39 +0100, Peter Tufvesson wrote: >> >> >> Ok, I have now made some more investigation. >> >> This is my understanding of how (part of) the process memory space is used >> >> 0x0 - 0x40000000 : Used by brk(). It starts low and grows up. Close to 1GB >> 0x4000000 - 0xc0000000 : Used by mmap(). It starts low and grows up. 2GB >> 0xfffffff - ? : Used by the stack. It starts high and grows down. 1GB. >> >> Is this correct? If so, WHY??? >> >> By doing this, you have effectively limited the amount of mmap()ped memory >> to 2GB and the amount of brk()ed memory to 1GB. So even if the process >> memory is in total 3GB, it is very unlikely that a process uses more than >> 1GB or 2GB (depending if it uses mmap() or brk() ) >> >> Solaris, on the other hand, lets the mmap() region start high at 0xf400000 >> and grow down. This way, the process is entitled to 3GB of EITHER brk() or >> mmap() memory! >> >> Am I totally wrong, or can the Linux code be dramatically and >> easily improved? >>
I'm going from (potentially flaky) memory here, so don't torch me too bad if I get something wrong. I don't remember the address boundaries exactly, but I think Solaris uses the following memory layout:
0-end_text program text end_text-??? heap (or brk(), whatever you want to call it) ???-stack_start mmap area, including dynamic libs, growing down stack_start-2GB stack - usually a fixed size considerably smaller than 1GB 2GB-4GB kernel - inaccessible to user mode
stack size is configurable using certain compiler/linker options, but there is essentially a 2GB vm limit per process. This has probably changed since the 64 bit chips have come out, but I haven't had the same level of experience with them that I had with the 32 bit architecture - I would assume that they used a fairly similar model. That layout seems to provide a little more flexibility in the balance between mmap/heap areas, although a badly fragmented heap could still potentially interfere with mmap-ing.
I agree the (seemingly arbitrary?) 1GB/2GB/1GB split could probably be improved on quite a bit, but I have no idea how much work that would entail... I suspect quite a lot... Then again, maybe there are completely valid reasons for the current state of affairs that I'm not aware of (actually, I'd almost bet on that...).
tw
-- +--------------------------+------------------------------+ | Tim Walberg | tewalberg@mediaone.net | | 828 Marshall Ct. | www.concentric.net/~twalberg | | Palatine, IL 60074 | | +--------------------------+------------------------------+ [unhandled content-type:application/pgp-signature] | |