Jemalloc, mmap и общая память?
Может ли jemalloc изменить выделение из разделяемой памяти? Функция FreeBSD dallocx() подразумевает, что вы можете предоставить указатель на использование для выделения, но я не вижу очевидного способа сказать jemalloc ограничить все распределения из этой памяти (а также не устанавливать размер и т.д.).
Функция dallocx() заставляет память, на которую ссылается ptr, быть доступной для будущих распределений.
Если нет, каков уровень усилий для такой функции? Я изо всех сил пытаюсь найти схему готового размещения, которая может выделяться из раздела разделяемой памяти, который я предоставил.
Аналогично, может ли jemalloc быть настроен на выделение из заблокированной области памяти для предотвращения обмена?
Не стесняйтесь указывать мне соответствующие разделы кода, которые требуют изменения и предоставляют любые идеи или предложения.
Идея, которую я изучаю, - это то, что вы можете создавать arenas/heaps для выделения в потоковой среде, поскольку jemalloc делает для минимизации конкуренции, концепция кажется масштабируемой для распределения областей общей памяти в многопроцессорной среде, то есть я создайте N областей разделяемой памяти с помощью mmap(), и я хочу использовать возможности jemalloc (или любой схемы распределения) для максимально эффективного распределения с минимальным конфликтом потоков из одной из этих разделяемых областей, то есть если потоки/процессы не имеют доступа к тем же общим областям и аренам, вероятность конкуренции минимальна, а скорость операции malloc увеличивается.
Это отличается от глобального распределения пула с помощью malloc() API, поскольку обычно для этого требуется глобальная блокировка, эффективно сериализирующая пространство пользователя. Я бы хотел этого избежать.
edit 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)
Ответы
Ответ 1
Да. Но это было неверно, когда вы задали вопрос.
Jemalloc 4 (выпущен в августе 2015 года) имеет пару пространств имен mallctl, которые были бы полезны для этой цели; они позволяют вам указывать per-arena, специфичные для приложения куски. В частности, пространство имен arena.<i>.chunk_hooks и arenas.extend mallctl. Существует интеграционный тест, который демонстрирует, как использовать этот API.
Что касается обоснования, я бы ожидал, что эффективные накладные расходы для обмена сообщениями, необходимые для понимания того, где соперничество на каком-либо сегменте памяти лежит, будут аналогичны накладным расходам только что конкурирующих, поскольку вы собираетесь деградировать в борьбу с кешем чтобы точно обновить "конкурентное" значение конкретной арены.
Поскольку jemalloc уже использует ряд методов для сокращения конкуренции, вы можете получить аналогичное поведение в среде с высокой степенью потоковой передачи, создав дополнительные арены с помощью opt.narenas. Это уменьшило бы конкуренцию, так как меньшее количество потоков было бы сопоставлено с ареной, но так как потоки эффективно округлены, возможно, вы все равно попадете в горячие точки.
Чтобы обойти это, вы можете сделать свой подсчет голосов и обнаружение точек доступа и просто использовать thread.arena mallctl интерфейс для переключите нить на арену с меньшим количеством соперников.
