Re: The direction of malloc?

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Tue, Dec 10, 2013 at 10:05:41PM +0100, OndÅej BÃlka wrote:
> > * Should we provide thread cache blocks to do provide some lockless allocation?
> 
> This is most low-hanging fruit that I aim for. We already use tls to
> determine arena so this should not be a issue.
> 
> We have fastbins that sorta do this but with several problems. 
> 1. They are not really lockless, for malloc they need a lock, only
> freeing will be when bug 15073 gets fixed.
> 
> Second problem is that fastbins are per-arena not per-thread which
> forces us to use atomic operations. These are expensive (typicaly more than 50 cycles).
> 
> Moving these to per-thread bins mostly just needs refactoring of current
> code to one that makes more sense.

With arenas-per-thread, you essentially have contention-free access,
which is not the same thing as lock-free, but not much worse.  You'll
have lock contention in per-thread arenas only when there are more
threads than arenas, which in the default case means that you have
more threads than twice the number of cores, which is too many threads
anyway.

> > To measure the program space usage, should we focus on both virtual size or just RSS?
> > This will require analysis like peak usage and mean usage I think. 
> 
> Virtual size depends how much we want to focus on 32bit systems with
> more than 512M of memory, otherwise higher virtual size does not cause
> much problems.

There are still many systems and programs that use rlimit(RLIMIT_AS)
to ration memory usage instead of using cgroups; virtual size is
important for those cases.  So while we need not stress on virtual
size that much, it cannot be completely ignored even on 64-bit.

Siddhesh