lkml.org 
[lkml]   [2000]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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]
\
 
 \ /
  Last update: 2005-03-22 13:55    [W:2.985 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site