Per thread arenas

[Daniel Micay]

On 29/04/15 01:30 AM, SNL wrote:
> 
> 
> I am planning to assign each thread its own arena, as per my
> understanding this is akin to having a per thread heap since arena
> management is completely independent of each other.
> 
> How this is know to affect performance and memory overheads ? I am sure
> this would depend a lot on application allocation patterns but are any
> generic numbers/data from past ?
> 
> In cases where allocation done by thread T1 is freed by thread T2, how
> does jemalloc handles it ? Is there any basic garbage collection or
> remote-free ( request to free by remote thread which owns the allocation
> ) implementation ? I see that this could lead to memory build up. 
> 
> Any inputs will be appreciated.

It returns memory to the arena it came from, so there will still be a
very low level of lock contention if lots of data is being sent.

There are thread caches so it will do this work in batches, but it won't
build up much.

Threads are assigned to arenas via round-robin so the default behaviour
is static assignment of threads to independent arenas as long as there
aren't more threads than arenas. There are 4*n_cores arenas by default
which covers a lot of cases without sharing them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150429/aee76336/attachment.sig>