jemalloc，mmap和共享内存？

Question

可以修改jemalloc以从共享内存分配吗？FreeBSD函数dallocx()意味着您可以提供一个用于分配的指针，但我看不出有一种明显的方法可以告诉jemalloc限制来自该内存的所有分配(或者设置一个大小等等)。

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

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

类似地，是否可以将jemalloc配置为从内存锁定区域分配以防止交换？

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

我正在探索的想法是--既然您可以创建在线程环境中分配的领域/堆，就像jemalloc为最小化争用而创建的那样，这个概念似乎可以扩展到在多处理环境中分配共享内存的区域，也就是说，我使用mmap()创建了N个共享内存区域，并且我希望利用jemalloc (或任何分配方案)的能力尽可能有效地分配线程争用，最小的线程争用来自那些共享区域之一，即如果线程/进程没有访问相同的共享区域和线程，争用的可能性很小，malloc操作的速度也增加了。

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

编辑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..chunk_hooks名称空间和arenas.extend mallctl选项是有用的。存在一个集成试验，它演示如何使用此API。

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

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

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