Re: [PATCH v3] benchtests: Add malloc microbenchmark

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, Jun 25, 2014 at 03:21:51PM +0530, Siddhesh Poyarekar wrote:
> On 25 June 2014 15:09, Will Newton <will.newton@linaro.org> wrote:
> > I expected to potentially see two inflection points in the curve. One
> > due to the single thread optimization in glibc that will make the
> > single threaded case disproportionally faster. I also expected to see
> > some kind of indication that I had run out of free CPU cores (and thus
> > context switch overhead increases). I ran the test on a 4 core i5
> > (hyper-threaded). I believe that's what is visible here:
> 
> There should be a third inflection point for glibc malloc at 8 *
> number of cores, where it stops allocating arenas per thread and you
> have contention for locks in addition to contention for CPU.  That's
> not visible in this graph because on a 4 core machine glibc malloc can
> go up to 32 threads without sharing arenas.
> 
No, this is simplistic benchmark, it does not measure thread contention,
as it does not do anything that could trigger it.

Here as it uses long running threads with static dependencies a conflicts will 
cause quick convergence to state where on each core runs a process until
it times out. A vmstat shows that there are around 2600 context switches
per second regardless what if benchmark is running or not.

To measure a multithread performance you would need to create some
multithread workload. For example try a spawning a short lived threads
that will do hundred allocations and frees then quit that could hit some
problems. Then focus in multithread bottlenecks, one is when you free
memory in another thread than where you allocated it.