resize! frees its new buffer with free instead of release
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
Direzione di ricerca
Leggi il finalizzatore di resize! in src/array.jl:659-661 e confrontalo con il finalizzatore del costruttore degli array in src/array.jl:129-131 e con release in src/pool.jl. Controlla i test pertinenti del finalizzatore o della gestione della memoria, poi eseguili; il lavoro è completato quando i buffer ridimensionati vengono rilasciati tramite release(buf), così si applicano il relativo comportamento di contabilizzazione e sincronizzazione.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The buffer that resize! allocates is freed by a finalizer that calls free(buf) (src/array.jl:659-661 at 0c02df0), whereas the array constructor's finalizer calls release(buf) (src/array.jl:129-131). That skips everything release does (src/pool.jl):
_allocated_bytesis never decremented for resized device and shared buffers, so the proactive-GC thresholds see memory that was freed long ago as still allocated;- on the LTS stack, the queues that may still reference the buffer aren't synchronized before freeing, which is the workaround for NEO 25.18 unmapping memory with work in flight (a GPU page fault that bans the context);
- the free doesn't use
ZE_DRIVER_MEMORY_FREE_POLICY_EXT_FLAG_BLOCKING_FREE.
So a vector that was resize!d and then becomes garbage while its last kernel is still running can take down the context on LTS. Using release(buf) in that finalizer, like the constructor does, should fix all three.
- Lingua principale
- Julia
- Stelle
- 217
- Fork
- 37
- Merge medio
- 17h 32m
- PR unite (30g)
- 24
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 JuliaGPU/oneAPI.jl
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
JuliaGPU/oneAPI.jl#663 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
JuliaGPU/oneAPI.jl#607 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di JuliaGPU/oneAPI.jl
Issue simili
-
Chains resumed from `initial_state` take `num_warmup + 1` warm-up stepsForse già presa @thevolatilebit l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
TuringLang/AbstractMCMC.jl#220 ·
-
found-by-agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
exanauts/SparseDirectSolver.jl#92 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
NumericalEarth/Breeze.jl#1051 ·
I maintainer di solito rispondono entro 1 giorno
-
lu_instance/qr_instance run a full factorization for FixedSizeArraysForse già presa @devmotion l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
JuliaArrays/ArrayInterface.jl#510 ·
-
Segfault on x86_64 with AVX: over-aligned vector storeForse già presa @vchuravy l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
EnzymeAD/Enzyme.jl#3775 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno