jemalloc，mmap和共享内存？

Question

是否可以修改jemalloc以从共享内存中分配？ FreeBSD函数dallocx()暗示你可以提供一个用于分配的指针，但我没有看到一种明显的方法告诉jemalloc限制来自该内存的所有分配（也不设置大小等）。

dallocx()函数使ptr引用的内存可用于将来的分配。

如果没有，这种功能的努力程度是多少？ 我很难找到一个可以从我提供的共享内存部分分配的现成分配方案。

同样， jemalloc可以配置为从锁定的内存区域分配以防止交换吗？

请随意向我指出需要修改的相关代码部分，并提供任何想法或建议。

我正在探索的想法是 - 因为你可以创建用于在线程环境中分配的竞技场/堆，就像jemalloc最小化争用一样，这个概念似乎可以扩展到在多处理环境中分配共享内存的区域，即我创建N个共享区域内存使用mmap() ，我想利用jemalloc （或任何分配方案）的功能尽可能有效地分配，最小的线程争用，来自那些共享区域，即如果线程/进程没有访问相同的共享区域和竞技场，争用的机会很小，并且malloc操作的速度增加。

这与使用malloc() API的全局池alloc不同，因为通常这些需要全局锁有效地序列化用户空间。 我想避免这种情况。

编辑2：

理想情况下这是一个api：

// init the alloc context to two shmem pools
ctx1 = alloc_init(shm_region1_ptr);
ctx2 = alloc_init(shm_region2_ptr);

(... bunch of code determines pool 2 should be used, based on some method
of pool selection which can minimize possibility of lock contention
with other processes allocating shmem buffers)

// allocate from pool2
ptr = malloc(ctx2, size)

Answer 1

是。 但是当你问这个问题时，情况并非如此。

Jemalloc 4（2015年8月发布）有几个mallctl命名空间，可用于此目的; 它们允许您指定每个竞技场，特定于应用程序的块分配挂钩。 特别是arena.<i>.chunk_hooks命名空间和arenas.extend mallctl选项是有用的。 存在一个集成测试 ，演示如何使用此API。

关于基本原理，我希望理解任何特定内存段上的争用所需的有效“消息传递”开销类似于仅仅竞争的开销，因为您将降级为在高速缓存行上竞争以准确更新特定竞技场的“争用”值。

由于jemalloc已经采用了许多技术来减少争用，因此您可以通过使用opt.narenas创建其他竞技场，在高度线程化的环境中获得类似的行为。 这将减少争用，因为更少的线程将被映射到竞技场，但由于线程实际上是循环的，所以无论如何都可能进入热点。

为了解决这个问题，你可以进行争用计数和热点检测，只需使用thread.arena mallctl接口将一个线程切换到竞争较少的竞技场。