This is the mail archive of the
mailing list for the glibc project.
Re: The direction of malloc?
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Wed, 11 Dec 2013 08:01:51 +0530
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <CANu=Dmi32gwk-hQ3dDbj0d4_gs3FWqt02+NmveXH1p03Vm+Mfg at mail dot gmail dot com> <20131210121622 dot GA5416 at domone dot podge> <52A75502 dot 6040500 at linux dot vnet dot ibm dot com> <20131210210541 dot GA19161 at domone dot podge>
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
> > 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.