This is the mail archive of the
mailing list for the glibc project.
Re: Malloc timeline.
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Allan McRae <allan at archlinux dot org>, libc-alpha at sourceware dot org
- Date: Tue, 17 Dec 2013 13:42:09 +0100
- Subject: Re: Malloc timeline.
- Authentication-results: sourceware.org; auth=none
- References: <20131217120834 dot GA29241 at domone dot podge>
On Tue, 2013-12-17 at 13:08 +0100, OndÅej BÃlka wrote:
> Then we could focus on important issues, we need to improve performance
> and per-thread cache for small allocations is easiest way to get these.
> This depends on resolving a malloc_set_state and signal safety.
We need to first agree on and/or create the benchmarks that we think
represent the targeted workloads and the performance characteristics
first. There might be "obvious" performance improvements we can do, but
I suspect that most of the changes we can apply probably have nontrivial
consequences in terms of performance.
Thus, performance-motivated changes will mostly be after benchmarks. I
don't think we can agree on benchmarks before 2.19, so they will be
2.20, and any performance-motivated changes will be later on. (For the
benchmarks, the release dates don't really matter though as long as we
don't expect users to run the benchmarks; I think this would be good to
do eventually, but I don't see this happening soon.)
I still think that starting with a discussion and building a documented,
shared, and agreed-upon understanding of the current issues should be
the first step (see my reply to your "The direction of malloc?" email).
What about starting with this?