Address space: what's safe?

[Martijn van Oosterhout]

On Fri, Mar 07, 2003 at 11:06:55AM +1100, Steve Blackburn wrote:
> Thank you all for the feedback so far.
> 
> 4.  Yes, I have seen this problem.  Speaking with Bill Clarke, it
>     seems that what has happend is that my fixed mmaps are causing
>     libraries to be unmapped with obviously nasty consequences---hence
>     I change the range I mapped more or less by trial and error.  The
>     latter is the process I want to avoid/automate.  Implicit in
>     Bill's feedback is that the libraries are not mmapped fixed, so if
>     I nailed down my space before they were loaded, then clashes might
>     be avoided?

Yes, definitly nail the space down so it won't accedently be used by someone
else. mmap()s cost almost nothing if you arn't using the space, so over
allocating is not too big a deal.

> 5.  Basically, I want to know (preferably ahead of time so constants
>     can be compiled in) is: What is the largest contigious range of
>     virtual memory linux will let, and where is it in the address
>     space?

Having a look at /proc/<pid>/maps shows several regions:
0x08000000 going up  = program address space + heap (brk())
0x40000000 going up  = mmap() space
0xC0000000 going down= stack

Looks like you can get a good just under 2GB there (0x40000000 - 0xC0000000).

> 6.  Between Bill & Martijn, the following solution makes a good start:
>       . find the biggest chunk of available vm by mmaping increasingly
>         large unreserved areas until they fail.
>       . use the above to mmap a fixed region of the appropriate size.

Looking at the /proc/<pid>/maps of apache can be very instructive.
-- 
Martijn van Oosterhout   <kleptog at svana.org>   http://svana.org/kleptog/
> Support bacteria! They're the only culture some people have.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20030307/d043a5b2/attachment.bin