¿Se puede modificar jemalloc para asignar desde la memoria compartida? La función FreeBSD dallocx() implica que puede proporcionar un puntero para usar en la asignación, pero no veo una forma obvia de decirle a jemalloc que restrinja todas las asignaciones de esa memoria (ni establezca un tamaño, etc.).
La función
dallocx()hace que la memoria a la que hace referenciaptresté disponible para asignaciones futuras.
Si no, ¿cuál es el nivel de esfuerzo para tal función? Estoy luchando por encontrar un esquema de asignación listo para usar que pueda asignar desde una sección de memoria compartida que proporcioné.
De manera similar, ¿se puede configurar jemalloc para asignar desde una región bloqueada de la memoria para evitar el intercambio?
Siéntase libre de señalarme las secciones de código relevantes que requieren modificación y proporcionar ideas o sugerencias.
La idea que estoy explorando es: dado que puede crear arenas/montones para asignar en un entorno de subprocesos, como lo hace jemalloc para minimizar la contención, el concepto parece escalable para asignar regiones de memoria compartida en un entorno de multiprocesamiento, es decir, creo N regiones de compartido memoria usando mmap() , y quiero aprovechar el poder de jemalloc (o cualquier esquema de asignación) para asignar de la manera más eficiente posible, con una mínima contención de subprocesos, desde esas regiones compartidas, es decir, si los subprocesos/procesos no acceden a la mismas regiones y arenas compartidas, la posibilidad de contención es mínima y se incrementa la velocidad de la operación malloc .
Esto es diferente a una asignación de grupo global con la API malloc() ya que generalmente requieren un bloqueo global que serialice de manera efectiva el espacio del usuario. Me gustaría evitar esto.
editar 2:
Idealmente una API como esta:
// 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)Sí. Pero esto no era cierto cuando hiciste la pregunta.
Jemalloc 4 (lanzado en agosto de 2015) tiene un par de espacios de nombres mallctl que serían útiles para este propósito; le permiten especificar ganchos de asignación de fragmentos específicos de la aplicación por arena. En particular, son útiles el espacio de nombres arena.<i>.chunk_hooks y las opciones arenas.extend mallctl . Existe una prueba de integración que demuestra cómo consumir esta API.
Con respecto a la justificación, esperaría que la sobrecarga efectiva de "mensajes" requerida para comprender dónde se encuentra la contención en cualquier segmento de memoria en particular sea similar a la sobrecarga de solo contender, ya que se degradará a contienda en una línea de caché para precisar actualizar el valor de "contienda" de una arena en particular.
Dado que jemalloc ya emplea una serie de técnicas para reducir la contención, podría obtener un comportamiento similar en un entorno con muchos subprocesos creando arenas adicionales con opt.narenas . Esto reduciría la contención ya que se asignarían menos subprocesos a una arena, pero dado que los subprocesos se rotan de manera efectiva, es posible que llegue a los puntos críticos de todos modos.
Para evitar esto, puede hacer el conteo de contiendas y la detección de puntos de acceso, y simplemente usar la interfaz thread.arena mallctl para cambiar un hilo a una arena con menos contención.