Inconsistent gdr read latency
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- c
- Área
- performance
Línea de trabajo
No source file or test is named. Start by reproducing the reported 3 KB, 100-read benchmark with the stated gdr mapping, page-locked host memory, alignment, and CU_POINTER_ATTRIBUTE_SYNC_MEMOPS settings; then inspect the gdr_copy_from_bar SSE4_1 implementation mentioned in the report. Done means identifying the cause of the alternating latency and documenting or correcting the behavior.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I have a memory allocator based on gdr which initially allocates a large chunk of gdr memory (e.g. 16 MB) and then allocates pieces of this chunk to the subsequent memory requests. During performance benchmarking, I noticed that the read latency of the same memory size fluctuates quite significantly and I can't understand why. For example, if I allocate 3KB memory read 100 times and do the same thing again and again, the average read time fluctuates between 4.5 us and 70 us (i.e. 4.5 -> 70 -> 4.5 -> 70 ...) even though the same piece of memory is allocated for every 100 reads.
Here are some details regarding my settings:
- I have set CU_POINTER_ATTRIBUTE_SYNC_MEMOPS to 1 for the entire chunk using cuPointerSetAttribute.
- The api reports "using SSE4_1 implementation of gdr_copy_from_bar" for read operation.
- The data is read into page-locked host memory allocated using cudaMallocHost.
- Both the gdr-mapped source pointer and the destination pointer are 128-bit aligned.
- The write latency is quite consistent.
- Lenguaje dominante
- C
- Estrellas
- 1.4k
- Forks
- 198
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/gdrcopy
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Proposal: honor `TMPDIR` in gdrcopy package build scriptsPosiblemente ocupada @efegokdemir la tomó hace 53 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
Todos los issues de NVIDIA/gdrcopy
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
SPIDevice selects an active-high device as soon as it is createdPosiblemente ocupada @mikeysklar la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
adafruit/circuitpython#11869 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
gnif/LookingGlass#1352 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100