[PATCH] benchtest: malloc tcache hotpath benchtest.

[Cupertino Miranda]

Hi Wilco,

On 25-04-2025 16:20, Wilco Dijkstra wrote:
> Hi Cupertino,
> 
> A few quick comments:
> 
>>   - forces single thread execution, reducing concurrency side-effects,
>>     like cache incoherence penalties due to simultaneous parallel writes
>>    to same cache pages;
> 
> Agreed.
> 
>>   - it prefills and saturates all tcache bins with chunks, before
>>     starting to collect any measurements;
> 
> I don't believe this is useful - it doesn't make a difference to the results.
> 
>> - input argument is now a max_allocation multipler, allowing it to
>>    increase max_allocation.
Right, the impact is indeed insignificant, considering that end result 
is dominated only by tcache operations. Just felt it would result in 
less variation when chunks were not available.
> 
> This isn't useful given the extremely skewed distribution. Basically
> even with a multiplier of 1024 the distribution of actual chunksizes
> remains almost identical:
> 
> multiplier = 1:
>    32: 6747
>    48: 498
>    64: 226
>    80: 124
>    96: 67
Did not verify actual distribution of allocations. This information is 
actually interesting. I would assume that randomness would result in a 
relative well distributed sizes of allocations.
> 
> multiplier = 1024:
>    32: 6722
>    48: 497
>    64: 214
>    80: 128
>    96: 76
The purpose of the multiplier, would be to test also for larger chunk 
size tcaches, but with that distribution it is useless.
> 
> In fact I get the same timings if I change get_block_size() to do just:
> 
>    return (rand_data & 31);
> 
> and the distribution looks like this:
> 
>    32: 6266
>    48: 1734
>    64: 0
>    80: 0
>    96: 0
> 
> Basically the skewed distribution means we are highly likely to first free a block
> and then immediately allocate another block of the same size! As a result the
> tcache will never overflow or underflow and we measure the hot paths.
> 
> If that is the goal, why not choose a single size?
With that distribution it is useless, but if we distribute well, it 
might measure some RSS values which might be interesting to get as well.
> 
>> For the purpose of measuring current overhead on tcache hotpaths, only
>> the execution with argument as 1 is relevant, since current tcaches are
>> limitted to allocations up to 1kb.
Right, I was thinking ahead to larger tcaches only.
> 
> If we purely want to benchmark the tcache hotpaths, we don't need to do
> anything as complex as this. We don't need multiple sizes, we only need a
> sequence of malloc/free that don't exceed the maximum entries in tcache.
Indeed, I did not want to go that far, but that is indeed right. :-)

Will check algorithm to properly distribute allocations and make it more 
significant.

Thanks,
Cupertino