This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Enhancing malloc
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 29 May 2013 12:33:27 +0530
- Subject: Re: Enhancing malloc
- References: <CANu=Dmj34hZoWr8A5dPThv14XUmP8vTgsxFLAbJ9jTTabRPqqA at mail dot gmail dot com> <201305282314 dot 29260 dot vapier at gentoo dot org>
On Tue, May 28, 2013 at 11:14:28PM -0400, Mike Frysinger wrote:
> On Tuesday 28 May 2013 07:11:01 Will Newton wrote:
> > Internally a number of benchmarks and workloads have been shown to
> > spend a relatively large amount of time in the allocator, so we've
> > been looking at improving performance of glibc malloc. Specifically I
> > think we would be looking more at the performance of the allocator
> > itself (e.g. locking overhead) rather than it's interaction with the
> > kernel VM.
> >
> > If we were to submit changes to the malloc implementation what set of
> > benchmark numbers would be required?
> > Would it be acceptable to have build time selection of multiple malloc
> > implementations?
> > Is anyone else already working on this?
>
> i wonder if we should require any changes to be preceded by the inclusion of
> tests and/or benchmarks, or maybe a new repo to hold things if those are too
> large ? having a centralized place of memory related tests/benchmarks that
> are agreed upon in terms of "this is the baseline you should use for
> optimizing" would go a long way. otherwise, we have one person setting up an
> environment, doing some work, and then throwing it all away once changes get
> merged which makes it harder for the next person to experiment.
> -mike
This could fit in well with the separate benchmark tests[1] idea I had
for string benchmarks. If Will can come up with independent benchmark
tests for malloc and friends, I can help to integrate those into
benchtests. Of course, if he comes up with tests integrated into the
benchtest framework then it would be even cooler ;)
Siddhesh
[1] http://sourceware.org/ml/libc-alpha/2013-04/msg00480.html