RE: [PATCH] Avoiding mmap fragmentation - clean rev

Chen, Kenneth W
2005-05-18T16:18:00Z

Wolfgang Wander wrote on Wednesday, May 18, 2005 8:47 AM
> I have to retract my earlier statement partially. While this patch
> does address the problems with munmap's tendency to fragment the maps
> areas, the issue it does not address, namely the lack of concentrating
> smaller requests towards the base is indeed important to us.
>
> With your patch the two large applications that triggered the
> fragmentation issue do still fail. So we still have a regression from
> 2.4 kernels to 2.6 with this fix.
>
> So I'd vote (hope it counts ;-) to either include your munmap
> improvements into my earlier avoiding-fragmentation-fix or use
> my (admittedly more complex) patch instead.
>
> I will append both a test case and the (nearly) final
> /proc/self/maps status of our failing application (cleansed slightly)
>
> The application fails with a request for 250MB but still had more
> than 1GB of memory distributed over the various holes. All
> maps are allocated via standard malloc/free calls which glibc
> translates into brk/mmap calls.

Yeah, it's going to be a challenge to satisfy a very large mmap mixed
with tons of small mmap/munmap. I would think a truly random mmap/munmap
size would coalesce mapping nicely. But apparently not in your case. I
will keep digging.