[PATCH] malloc: Count tcache entries downwards

[Cupertino Miranda]

Hi DJ, Wilco, Florian,

I wonder if we do not have a race around mallopt already.
First look at the do_set_... functions seem to change shared variables 
not really taking any consideration for concurrent accesses.

Cheers,
Cupertino


On 07-05-2025 12:15, Wilco Dijkstra wrote:
> 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