This is the mail archive of the
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: Torvald Riegel <triegel at redhat dot com>
- To: Jörn Engel <joern at purestorage dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Will Newton <will dot newton at linaro dot org>, Joern Engel <joern at purestorage dot org>
- Date: Tue, 26 Jan 2016 18:20:25 +0100
- Subject: Re: malloc: performance improvements and bugfixes
- Authentication-results: sourceware.org; auth=none
- References: <1453767872-19161-1-git-send-email-joern at purestorage dot com> <1453810961 dot 4592 dot 100 dot camel at localhost dot localdomain> <20160126171435 dot GG5745 at Sligo dot logfs dot org>
On Tue, 2016-01-26 at 09:14 -0800, JÃrn Engel wrote:
> On Tue, Jan 26, 2016 at 01:22:41PM +0100, Torvald Riegel wrote:
> > Could you describe the workloads you used to select / validate these
> > changes? While several of the items you listed might be generally
> > useful, others are certainly workload-specific, at least as far as
> > choices regarding trade-offs are concerned.
> Think a single heavily multithreaded process consuming most of the
> system, then make it latency-sensitive and you are pretty much there.
> I think the hugepage stuff is pretty unique to us, but most of the rest
> should apply to anything big and performance-sensitive.
How do the allocation patterns look like? There can be big variations
in allocation frequency and size, lifetime of allocated regions,
relation between allocations and locality, etc. Some programs allocate
most up-front, others have lots of alloc/dealloc during the lifetime of