jemalloc, mmap и общая память?

Question

Можно ли изменить jemalloc для выделения из общей памяти? Функция FreeBSD dallocx() подразумевает, что вы можете предоставить указатель для использования при распределении, но я не вижу очевидного способа сказать jemalloc ограничить все выделения из этой памяти (ни установить размер, и т. д.).

dallocx() функция вызывает память, на которую ссылается ptr быть доступным для будущих ассигнований.

Если нет, каков уровень усилий для такой функции? Я изо всех сил пытаюсь найти готовую схему распределения, которая может выделить из раздела общей памяти, который я предоставил.

Точно так же, может jemalloc быть настроен для выделения из заблокированной области памяти, чтобы предотвратить подкачку?

Не стесняйтесь указывать мне на соответствующие разделы кода, которые требуют модификации, и предоставлять любые идеи или предложения.

Идея, которую я исследую, заключается в том, что вы можете создавать арены / кучи для размещения в многопоточной среде, так как jemalloc позволяет минимизировать конкуренцию, концепция кажется масштабируемой для выделения областей разделяемой памяти в многопроцессорной среде, т.е. я создаю N областей разделяемой памяти, используя mmap() и я хочу использовать силу 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 года) имеет пару mallctl пространства имен, которые были бы полезны для этой цели; они позволяют вам указывать для каждой арены специфичные для приложения хуки распределения чанков. В частности, arena.<i>.chunk_hooks пространство имен и arenas.extendmallctl варианты полезны. Существует интеграционный тест, который демонстрирует, как использовать этот API.

Что касается логического обоснования, я ожидаю, что эффективные накладные расходы на "обмен сообщениями", необходимые для понимания того, где находится конфликт в каком-либо конкретном сегменте памяти, будут аналогичны накладным расходам только на состязание, так как вы собираетесь перейти на состязание в строке кэша, чтобы обновить значение "состязания" конкретной арены.

Поскольку jemalloc уже использует ряд методов для уменьшения конкуренции, вы можете получить аналогичное поведение в многопоточной среде, создав дополнительные арены с opt.narenas, Это уменьшит конкуренцию, так как на арене будет отображаться меньше потоков, но поскольку потоки эффективно циклически перерабатываются, возможно, вы все равно попадете в горячие точки.

Чтобы обойти это, вы можете сделать подсчет конфликтов и обнаружение горячих точек, и просто использовать thread.arenamallctl интерфейс для переключения потока на арену с меньшим количеством конфликтов.