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 | | +--------------------------+------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:07 EST