This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] benchtests: Add malloc microbenchmark
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 25 Jun 2014 15:21:51 +0530
- Subject: Re: [PATCH v3] benchtests: Add malloc microbenchmark
- Authentication-results: sourceware.org; auth=none
- References: <1403196368-26785-1-git-send-email-will dot newton at linaro dot org> <20140625092926 dot GA28367 at domone dot podge> <CANu=DmgY1ZZODXSMhnM4ajNQzv3YJSOH_6EgCbcXtnoymPRt7g at mail dot gmail dot com>
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.
Siddhesh
--
http://siddhesh.in