[PATCH] malloc: Count tcache entries downwards

[Wilco Dijkstra]

Hi DJ,

> It is far easier for threads to just compare *actual* counts with a
> changing policy limit.

It seems easier, but that doesn't mean it works well. Changing global variables
used concurrently by many threads without atomics causes many issues...

Even if you don't get concurrency issues, chunks would be locked into tcache
until the thread terminates if you lower tcache_bins or decrease tcache_count.
The same issue exists for the fast bins.

And the question is, who is interested in changing tcache dynamically?
Is there any application that changes mxfast dynamically? I can see it might
be useful for debugging and testing malloc, but we don't need to add public
interfaces to do that.

> Also, if "counts" is now counts of *empty* tcache slots, it needs a more
> obvious name.

Like "num_slots" or "free_entries"?

>> If we do this periodically then we may not even need to place restrictive limits
>> on the number of tcache entries
>
> Given what I've seen of fastbins and fragmentation, some way to limit
> growth should always be considered for new malloc features.

It would still be a limit on growth if it is done regularly. Even today it would be
good to flush tcache every now and again.

Overall an allocation budget seems better, ie. set a maximum amount of memory
cached in tcache. I'll do some experiments, but if we want to remove fastbins in
the future, we need to improve tcache effectiveness.

Cheers,
Wilco