[PATCH v4] benchtest: malloc tcache hotpath benchtest.

[Cupertino Miranda]

Hi Wilco,

On 12-05-2025 11:09, Wilco Dijkstra wrote:
> Hi Cupertino,
> 
>> I noticed that there was an unexpected performance loss when alloc_size
>> was 1024.
>> While exploring I notice that for alloc_size 1016 I get:
>>   "time_per_iteration": 14.3453
>> and for 1017:
>>   "time_per_iteration": 16.3697.
>> Could this be related to CPU cache effects? No idea!
> 
> Quite likely, especially since you're still measuring latency. You might get bank
> conflicts depending on the addresses used, and that can increase latency.
> 
> +++ b/benchtests/Makefile
> @@ -329,8 +329,10 @@ ifeq (${BENCHSET},)
>   bench-malloc := \
>     calloc-simple \
>     calloc-thread \
> +  calloc-tcache \
> 
> Not in alphabetic order, so it fails tests...
Oh, I was not aware of that check.
> 
> +/* Allocate and free blocks in a random order.  */
> +static size_t
> +malloc_benchmark_loop (void *elem)
> +{
> +  size_t iters = 0;
> +  while (!timeout)
> +    {
> +      elem = TEST_FUNC (alloc_size);
> +      free (elem);
> +      iters++;
> +    }
> 
> This still measures latency rather than throughput.
I think we are measuring throughput, although presenting it in nanosecs 
per opeartion.
I don't know what it means to measure latency in this particular case.

Can you please clarify what do you mean?

> 
> +  /* Preload tcache not to measure non tcache allocation time.  */
> +  elem = TEST_FUNC (alloc_size);
> +  free (elem);
> 
> I don't believe this makes any difference on the timescales we're using.
> 
> +  TIMING_NOW (start);
> +  *iters = malloc_benchmark_loop (elem);
> +  TIMING_NOW (stop);
> 
> This gives a use after free compilation error...
Oups, using older compiler here.

Cheers,
Cupertino