This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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. Siddhesh
Attachment:
pgpb3UQCYu23F.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |