This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]