On Mon, Mar 09, 2015 at 11:02:22AM +0100, Leonhard Holz wrote:
The current malloc benchtest does use multiple threads, but they work on
independent block lists so that every thread uses its own arena only. The
following patch adds a version of the benchmark with all threads working on
the same block list, so that it is likely that a thread free()s a block in
an arena of a different thread and by this causes lock contentation on that
arena. Therefore the performance of the malloc locking mechanism is included
in the measuring.
Unfortunately the access to an entry in the shared block list has to be
protected by a mutex. The time taken for acquiring the mutex is included in
the measured time per iteration, so that the iteration time of the
concurrent malloc benchmark is not directly compareable the time of the
per-thread benchmark.
It might be a better idea to simulate producers and consumers for such
a benchmark. Size variance is not an issue in this case since we're
not measuring overhead due to consolidation. A simple model would be
to have one thread malloc blocks and pass it on to another thread,
which then frees the block. You could scale this to a number of
producers and consumers, either working in pairs or on a couple of
common pools.