Re[2]: your mail on mmap() to the kernel list

[Peter Zaitsev <pz@spylog.ru>]

Hello Andrea,

Tuesday, December 04, 2001, 7:48:24 PM, you wrote:

>> AA> You can fix the problem in userspace by using a meaningful 'addr' as
>> AA> hint to mmap(2), or by using MAP_FIXED from userspace, then the kernel
>> AA> won't waste time searching the first available mapping over
>> AA> TASK_UNMAPPED_BASE.
>> Well. Really you can't do this, because you can not really track all of

AA> I can do this sometime, I did it in the patch I posted for example.
Well. You're really easy may do this only in such dumb test example
then you do something real between mmaps even memory allocation in
multi threaded program you will not able to track it.

AA>  If
AA> you want transparency and genericity you can still do it in userspace
AA> with an LD_LIBRARY_PATH that loads a libc that builds the hole-lookup
AA> data structure (tree?) internally, and then passes the hint to the
AA> kernel if the program suggests 0.

Well but it's not really easy and right thing to do as you will also
need to write your own memory allocator (as standard one uses mmap so
you can get in recursive loop).  And also it will be really
platform/kernel dependent as different kernels may use different
addresses there user part of address space available for mmaping
starts.

AA> OTOH I prefer those kind of algorithms (if needed) to be in the kernel
AA> so they're faster/cleaner and also a lib would need some magic knowledge
AA> about kernel internals virtual addresses to do it right.
Yes. I'm quite agree with that.  Also if you have one tree implemented
it should not be too hard to have a second tree indexed by other
field.

>> AA> the common case should matter more I guess, and of course userspace can
>> AA> just fix this without any kernel modification by passing an helpful
>> AA> "addr", to the mmap syscall with very very little effort.  Untested
>> AA> patch follows:
>> 
>> Could you please explain a bit how this the hint works ? Does it tries

AA> man 2 mmap, then search for 'start'

I've read it of course :)

>> only specified address or also tries to look up the free space from
>> this point ?

AA> in short it checks if there's 'len' free space at address 'start', and
AA> if there is, it maps it there, without having to search for the first
AA> large enough hole in the heap.

I understand it but does it start so search standard way from the low
addresses or it looks it above the hint address before looking at
lower addresses ?


-- 
Best regards,
 Peter                            mailto:pz@spylog.ru