Re: Fw: [Bug 4520] New: /proc/*/maps fragments too quickly compared to

Wolfgang Wander
2005-05-10T13:23:55Z

Arjan van de Ven writes:
> On Mon, May 09, 2005 at 02:26:51PM -0700, Andrew Morton wrote:
>
> > Possibly for the 2.6.12 release the safest approach would be to just
> > disable the free area cache while we think about it.
>
> the free area cache either is historically tricky to be fair; it has the
> thankless job of either keeping at the "ealiest" small hole (and thus being
> useless if most allocs are bigger than that hole) or leaving an occasionally
> small hole alone and thus fragmenting memory more, like you've shown.
> I like neither to be honest; the price however is a higher lookup cost (well
> mitigated if vma merging is really effective)

My approach tries to find a compromise. It changes the behaviour so
that is keeps the size of the largest hole it found below the cache
so that it knows for what request size to disregard the cache and
start from scratch. By doing so it also avoids setting the cache
to the latest munmap-ed region (and adjusts the largest_hole below
the cache pointer instead). Setting the cache pointer to the latest
munmap was also a major contributor to the fragmentation:

Imagine 5 consecutive maps of 1K, then free map 2,4,3 in that order.
The next mmap will get its space from the original area 3 leaving gaps
on either side.

But I'm of course also very happy if the original 2.4 behaviour
without caching is restored...

Wolfgang