Inconsistent gdr read latency
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- c
- Ambito
- performance
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- C
- Stelle
- 1.4k
- Fork
- 198
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NVIDIA/gdrcopy
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Proposal: honor `TMPDIR` in gdrcopy package build scriptsForse già presa @efegokdemir l’ha presa 53 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
Tutte le issue di NVIDIA/gdrcopy
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
SPIDevice selects an active-high device as soon as it is createdForse già presa @mikeysklar l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
adafruit/circuitpython#11869 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
gnif/LookingGlass#1352 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100