This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc using mprotect
Hello,
> I tried
> while (1) malloc(1024);
> and once it eated the brk heap, the syscall sequence was mmap, munmap half o
> f it, mprotect first 32K, then mprotect 4K with increasing addresses, then
> again mmap etc.
Ok, looks like a bug to me, it wasn't intended anyway. top_pad isn't
used in malloc_extend_top for non-main arenas, and I misremembered:
top_pad is actually set to 0 by default. Maybe we should set it to
32k, 64k or something like that?
> mprotect does not do any segment merging in 2.4, so each single page
> consumes one vma.
Ahem.. oh my god! Let me make sure I understand this:
- mmap(...128k..) still takes one VMA, not 32.
however
- calling mmap(..4k..) successively _even at consecutive addresses_
now always takes 32 VMAs
When exactly was this introduced and why?
> The number of vmas has upper limit (2<<16 in Linus kernel's,
> in -ac kernels it is just the default and it is adjustable through
> /proc/sys/vm/max_map_count).
That sounds like a reasonable limit to me.
> But Linus does not want to do anything with mprotect merging unless we
> convince him why glibc needs to do the mprotect stuff.
Personally, I think such merging is worth it in any case! (Is there a
reason why it would be prohibitively exepensive now?) However, as a
short term workaround, we should set top_pad to at least 32k in
malloc, and make sure it is used even for non-main arenas (I'll send a
patch later).
Regards,
Wolfram.