Re: Repost: could ia32 mmap() allocations grow downward?

[Wayne Whitney]

On Thu, 13 Dec 2001, Petr Vandrovec wrote:

> Maybe we should move to bug-glibc instead, as there is no way to force
> stdio to not ignore mallopt() parameters, it still insist on using
> mmap, and I think that it is a glibc2.2 bug.

OK, that makes sense for the glibc2 subthread of this discussion.  Would
you mind submitting the bug report, as you have a better command of the
issues than I do?  Or if you want, I can do it and just quote you.  :-)

> P.S.: I did some testing, and about 95% of mremap() allocations is
> targeted to last VMA, so no VMA move is needed for them. But no Java
> was part of picture, only c/c++ programs I use - gcc, mc, perl.

Ah, so this is important data.  It shows that the mmap() grows downward
strategy will hurt the common case.  I don't have any handle on the
magnitude of this effect, but if it is significant, then I would have to
agree that supporting the legacy brk() apps is not as important as keeping
mremap() of the last VMA cheap.  How expensive is moving a VMA, and how
often do programs mremap()?

How about the idea of modifying brk() (or adding an alternative) to move
VMAs out of the way as necessary?  This way the negative impact (of moving
VMAs) is only borne by the legacy brk() using app.  Or is there some other
downside that I am missing?

Wayne