This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/14581] memalign allocations are often not reused after free
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 30 Jul 2018 10:39:45 +0000
- Subject: [Bug malloc/14581] memalign allocations are often not reused after free
- Auto-submitted: auto-generated
- References: <bug-14581-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14581
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
--- Comment #14 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #13)
> > This is probably the right tradeoff still when the
> > alternative is permanent-ish fragmentation for the process lifetime, but
> > maybe there are ways to make it better/less-costly.
>
> Other approaches would be to search for a smaller, sufficiently aligned
> allocation. This might not be so bad with the current glibc allocator and
> its unsorted bins.
We should test this approach, but I suspect keeping the pre-gap, allocation,
and post-gap together in some way will yield the best fragmentation reducing
results. This is just a hunch though, we should continue to use the trace,
simulation, and other tools we have to derive a data-driven approach to making
changes in malloc. Then we should validate the changes to show the model we
have is predicting real behaviour in the applications e.g. re-run fluentd +
ruby with the changes and see if we managed to make an RSS difference (if
fluentd suffers from this problem, we don't know).
> Or we could use a separate allocator for aligned allocations which has
> separate freelists for different alignments, and sorts the freelist bins by
> size and alignment. However, this will prevent us from reusing memory which
> has been used for aligned allocations for unaligned ones.
This is definitely outside of the box thinking, and takes us down a path of
heaps which have specific properties. I was thinking about this the other day,
but need to re-review the literature on this topic.
I think the best approach in terms of value for the design is going to be
grouping together the aligned allocation.
--
You are receiving this mail because:
You are on the CC list for the bug.