[PATCH] malloc: Count tcache entries downwards

[Cupertino Miranda]

On 07-05-2025 13:27, Cupertino Miranda wrote:
> 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.
Not entirely true, __libc_mallopt locks the main arena, still I think 
this might not be enough.
> 
> 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
>