Re: malloc using mprotect

[Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>]

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.