Re: Malloc timeline.

[Torvald Riegel <triegel at redhat dot com>]

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?