[Bug malloc/14581] memalign allocations are often not reused after free

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14581

--- Comment #16 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Mika Fischer from comment #15)
> Created attachment 11763 [details]
> Example case for image processing use-case
> 
> We hit this issue (or at least I assume it is this issue) in production.
> 
> Our use-case is that we have a loop with:
> - two large aligned allocations (large temporary images)
> - followed by a small unaligned allocation (the result)
> - the large allocations are freed, the small result is kept
> 
> For some sizes (see attached program) this leads to glibc never freeing any
> memory! The attached program demonstrates the issue. It runs out of memory
> in seconds...

Yes, it's the same case.

In your example the 16MiB aligned block needs worst case 16MiB + alignment +
MIN_SIZE, but memalign, after getting back that block, will split the leader
and header from the block and reuse them. If a long-lived allocation takes one
of leader/remainder blocks then we can no longer find enough space on a
subsequent memalign to reallocate the 16MiB + alignment + MIN_SIZE block, and
we end up having to extend the heap again by 16MiB + alignment + MIN_SIZE. This
continues every iteration, growing the heap by sizes which are just shy of the
needed space.

Your only workaround is the usual trick:
GLIBC_TUNABLES=glibc.malloc.mmap_threshold=10485760 strace -ff -ttt -o
loop2.log ./memalign-loop
Which avoids the dynamic thresholding which is moving the allocation from mmap
to the brk heap.

Looking over the code again, I think the problem is really this:

4698   /* Call malloc with worst case padding to hit alignment. */
4699 
4700   m = (char *) (_int_malloc (av, nb + alignment + MINSIZE));
4701 

We need to avoid this pessimistic allocation and scan the bins ourselves
looking for a suitably aligned allocation. It's there, and ready to be used,
but not if we lazily use _int_malloc instead of scanning the bins ourself
first. I think such a scan will yield the best results overall and be straight
forward to implement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.