mmap doesn't "wrap?"

mmap doesn't "wrap?"

[grg22]

It looks to me as though mmap will try to grab a region of memory whose
address is greater than or equal to the suggested start address passed in
the call.  I suppose it does this because it traverses the free list in
ascending address order.  If it can't find enough memory above the
requested address, then the mmap fails, claiming ENOMEM; and it does this
even when you've got gigs of wide open address space below the suggested
address.

One effect of this is that if you specify an address of 0 (saying "I don't
care"), the mmap seems to start above 0x40000000 by default, and forever
ignores the gigabyte of address space below that.  This seems undesirable,
especially when your chunk of memory requested would fit below 0x4000000
but can't fit above it (due to memory fragmentation, or because you've
already used up the rest of it!).

I don't know if the right thing would be to change the behavior of
get_unmapped_area() to "wrap" from the beginning of the free list when it
can't find anything above the given address, or just add a failure clause
into do_mmap() to try again starting from 0 (or something else?).  


(Yes, I've patched my rlimits so I can access 3GB virtual and yes, I 
commit the sin of addressing the 32-bit community only on this more 
general mailing list: apologies to you lucky 64-bit folks.)

thx,
grg
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: mmap doesn't "wrap?"

[Kanoj Sarcar]

> 
> It looks to me as though mmap will try to grab a region of memory whose
> address is greater than or equal to the suggested start address passed in
> the call.  I suppose it does this because it traverses the free list in
> ascending address order.  If it can't find enough memory above the
> requested address, then the mmap fails, claiming ENOMEM; and it does this
> even when you've got gigs of wide open address space below the suggested
> address.
> 
> One effect of this is that if you specify an address of 0 (saying "I don't
> care"), the mmap seems to start above 0x40000000 by default, and forever
> ignores the gigabyte of address space below that.  This seems undesirable,
> especially when your chunk of memory requested would fit below 0x4000000
> but can't fit above it (due to memory fragmentation, or because you've
> already used up the rest of it!).
> 
> I don't know if the right thing would be to change the behavior of
> get_unmapped_area() to "wrap" from the beginning of the free list when it
> can't find anything above the given address, or just add a failure clause
> into do_mmap() to try again starting from 0 (or something else?).  
> 
> 
> (Yes, I've patched my rlimits so I can access 3GB virtual and yes, I 
> commit the sin of addressing the 32-bit community only on this more 
> general mailing list: apologies to you lucky 64-bit folks.)
> 
> thx,
> grg
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
> 


Look at my patch for get_unmapped_area() at

	http://reality.sgi.com/kanoj_engr/garea.html

This has been submitted to Linus previously, unfortunately, it has not
been accepted. The current get_unmapped_area() is not POSIX compliant 
according to my thinking.

Regarding TASK_UNMAPPED_BASE, you can browse

	http://reality.sgi.com/kanoj_engr/tuning.html

which has some pointers on how to use the 3Gb user space judiciously. 
Basically, you can tune TASK_UNMAPPED_BASE to 0x10000000, if your apps
are "well-behaved".

Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/