I can reproduce this issue.

Allocating a large number of 64-byte chunks and freeing a large number of 64-bytes chunks (all fastbin allocations less than 128 bytes on x86_64) will never trigger the fastbin consolidation (consolidation triggered by a free of size 65k or larger) that eventually leads to full trimming.

The solution is to call `mallopt (M_MXFAST, 0)'. If you need trimming and have lots of small objects you must disable fastbins.

The concept of "fastbins" is completely opposed to trimming. The point is that you want to have a pool of small bins that are easy to use and not consolidated. Unfortunately you can't trim unless you consolidate the fastbins. You don't want to consolidate on each free because that's costly.

However, you are correct in that M_TRIM_THRESHOLD is not honoured because it interacts with the default value for M_MXFAST.

Would updating the documentation help?

That is:

(a) Document M_MXFAST, since it is currently not documented in the glibc manual.

(b) Indicate in M_TRIM_THRESHOLD that if M_MXFAST is not disabled that trimming will not happen unless a block of at least 65k is done.

Comments?

IMHO a real solution would be to limit the number of fastbins. There's no benefit in having an infinite sized fastbin pool.

My suggestion is as follows:

(a) Use mallinfo() to look at the number of bytes being used by fastbins e.g. fsmblks.

(b) If this size exceeds your application specific requirements for fastbins then call malloc_trim().

You can do (a) whenever your application is doing normal housekeeping, and you can do (b) whenever required.

We provide a lot of flexibility here, but we want the default cause to perform quickly, and use memory to increase that performance.

Limiting fastbins by default is going to require much more discussion and information about exactly what was consuming memory in "KDE" (which you can check by using mallinfo() to examine what is in use. Any new heuristics will need to be carefully balanced against the existing high performance implementation.

Does that make sense?

The problem is that we're moving the burden of such fine grained memory management to the application developer, instead of it being done by the malloc implementation.

KDE has more than 100 applications, it's not viable to study memory requirements for each application.

How do we handle dependencies that are not part of the KDE project? I've seen savings of 300MB on the virtuoso server.


GNOME probably has the same problem. It's a matter of trying it out.

Please file another BZ where we can discuss enhancements to the glibc allocator and the use of fastbins. Please provide detailed mallinfo statistics for KDE and gnome and use cases where you are seeing problems with fastbins and memory consumption.

This particular issue is about free() not honouring M_TRIM_THRESHOLD, which I plan to fix by enhancing the documentation to explain how fastbins interact with trimming.

Was that additional bug filed? The man page for malloc_trim seems to be entirely inaccurate and the need to call it manually seems remarkably Google-proof, fixing the allocator to make it less needed (as well as improving the docs) seems like a good idea. 

If it was filed, linking to it from this bug seems useful.

(In reply to Jon Levell from comment #7)
> Was that additional bug filed? The man page for malloc_trim seems to be
> entirely inaccurate and the need to call it manually seems remarkably
> Google-proof, fixing the allocator to make it less needed (as well as
> improving the docs) seems like a good idea. 
> 
> If it was filed, linking to it from this bug seems useful.

I don't know if an additional bug was filed.

I've added to my list that the man pages project needs an update for this also.

I'm moving this to rhel-7.5 for later review.

My expectation is that this is unsolvable with existing fastbins by virtue of the semantics of the way the trimming works, it's a per-free trim check not a cumulative integral of the freed back value.

Instead the solution I would propose is disabling fastbins and moving to lockless per-thread caches which have shown much better performance. These per-thread caches would be limited to a fixed RSS size. We have this work upstream in the dj/malloc branch but it still needs more operational hours of testing before we can deploy this into RHEL. However, that doesn't stop us from planning to move in that direction.

If anyone on this ticket has any objections to this plan, please comment here.

We have thread-locale caches upstream now, but we also found fastbins continue to provide a significant performance benefit. The next step is going to be to look at limiting the number of fastbins in use. This work still needs to be done upstream.

We are going to track this issue as part of this upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=14827

I'm going to mark this bug as CLOSED/UPSTREAM. When we have an upstream solution in place we can consider the backport to RHEL7 or RHEL8 as appropriate.