[PATCH] benchtest: malloc tcache hotpath benchtest.

[Wilco Dijkstra]

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.

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

multiplier = 1024:
  32: 6722
  48: 497
  64: 214
  80: 128
  96: 76

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?

> 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.

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.

Cheers,
Wilco