Re: [PATCH] Avoiding mmap fragmentation - clean rev

Wolfgang Wander
2005-05-23T18:25:49Z

Chen, Kenneth W wrote:
> Andrew Morton wrote on Thursday, May 19, 2005 3:55 PM
>
>>Wolfgang Wander <wwc@rentec.com> wrote:
>>
>>>Clearly one has to weight the performance issues against the memory
>>> efficiency but since we demonstratibly throw away 25% (or 1GB) of the
>>> available address space in the various accumulated holes a long
>>> running application can generate
>>
>>That sounds pretty bad.
>>
>>
>>>I hope that for the time being we can
>>> stick with my first solution,
>>
>>I'm inclined to do this.
>>
>>
>>>preferably extended by your munmap fix?
>>
>>And this, if someone has a patch?
>
>
>
> 2nd patch on top of wolfgang's patch. It's a compliment on top of initial
> attempt by wolfgang to solve the fragmentation problem. The code path
> in munmap is suboptimal and potentially worsen the fragmentation because
> with a series of munmap, the free_area_cache would point to last vma that
> was freed, ignoring its surrounding and not performing any coalescing at all,
> thus artificially create more holes in the virtual address space than necessary.
> Since all the information needed to perform coalescing are actually already there.
> This patch put that data in use so we will prevent artificial fragmentation.
>
> It covers both bottom-up and top-down topology. For bottom-up topology,
> free_area_cache points to prev->vm_end. And for top-down, free_area_cache points
> to next->vm_start.

Works perfectly fine here. All my tests pass and our large applications
are happy with this patch.

Thanks Ken for your patience with my lack of it ;-)

Wolfgang