c - jemalloc, mmap and shared memory? -


can jemalloc modified allocate shared memory? freebsd function dallocx() implies can provide pointer use allocation, don't see obvious way tell jemalloc restrict all allocations memory (nor set size, etc).

the dallocx() function causes memory referenced ptr made available future allocations.

if not, level of effort such feature? i'm struggling find off-the-shelf allocation scheme can allocate shared memory section provided.

similarly, can jemalloc configured allocate locked region of memory prevent swapping?

feel free point me relevant code sections require modification , provide ideas or suggestions.

the idea exploring — since can create arenas/heaps allocating in threaded environment, jemalloc minimize contention, concept seems scalable allocating regions of shared memory in multiprocessing environment, i.e. create n regions of shared memory using mmap(), , want leverage power of jemalloc (or allocation scheme) allocate efficiently possible, minimum thread contention, 1 of shared regions, i.e. if threads/processes not accessing same shared regions , arenas, chance contention minimal , speed of malloc operation increased.

this different global pool alloc malloc() api since these require global lock serializing user-space. i'd avoid this.

edit 2:

ideally api this:

// init alloc context 2 shmem pools ctx1 = alloc_init(shm_region1_ptr); ctx2 = alloc_init(shm_region2_ptr);  (... bunch of code determines pool 2 should used, based on method of pool selection can minimize possibility of lock contention other processes allocating shmem buffers)  // allocate pool2 ptr = malloc(ctx2, size) 

yes. not true when asked question.

jemalloc 4 (released in august of 2015) has couple of mallctl namespaces useful purpose; allow specify per-arena, application-specific chunk allocation hooks. in particular, arena.<i>.chunk_hooks namespace , arenas.extend mallctl options of use. integration test exists demonstrates how consume api.

regarding rationale, expect effective "messaging" overhead required understand contention on particular memory segment lies similar overhead of contending, since you're going degrade contending on cache line accurately update "contention" value of particular arena.

since jemalloc employs number of techniques reduce contention, similar behavior in highly threaded environment creating additional arenas opt.narenas. reduce contention fewer threads mapped arena, since threads round-robined, it's possible hot-spots anyway.

to around this, contention counting , hotspot detection, , use thread.arena mallctl interface switch thread onto arena less contention.


Comments

Popular posts from this blog

c# - Validate object ID from GET to POST -

node.js - Custom Model Validator SailsJS -

php - Find a regex to take part of Email -