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]

Re: Enhancing malloc


On 05/28/2013 11:14 PM, 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.

Fully agree.

The purpose of the bench tests is exactly to solve this problem.

I'd like to see things added to bench/ for malloc that show
before and after performance.

That way the machine maintainers can just run `make bench' and
post results.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]