Parallelize subproblem solves in SiLO/address memory leak on Linux

Aperta
  • Qualcosa non va?
#21 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
data

Direzione di ricerca

The issue describes memory retention in processAllTrials_Async and parallel SiLO subproblem solves, but names no source files or tests. Start by locating those entry points and reading the existing trial loop and SiLO solve flow. Define a design for saving subproblems, distributing them across workers, and gathering results; done means the pipeline handles the proposed parallel work and addresses the memory issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug enhancement

Two probably-related issues, one a bug, the other an enhancement:
1)
Kort Driessen had encountered a failure on very long recordings under Linux, that may be the cause of inefficiencies in our codeocean pipeline.

Kort's diagnosis was:
Memory allocated during each iteration of processAllTrials_Async’s trial loop was not being returned to the operating system.
MATLAB clear did not actually cause the process’s resident memory to fall.
He tried malloc_trim, changing relevant glibc settings, and other approaches, without solving it.
He concluded that the reliable way to recover the trapped memory was to terminate the process entirely.

Kort’s workaround
His solution was to sub-batch the acquisition:
Split the acquisition into batches.
Run each batch in its own process.
Save intermediate results before that process exits.
Let the process terminate, which returns its memory to the OS.
Start a fresh process for the next batch and resume from the saved intermediate state.
He implemented this in his fork of ophys-slap2-analysis, on the wisc_dev branch. At the time of the email, he said his fork was about 15 commits behind Allen’s main branch but that he could rebase it.

Carter Peene then took Kort’s write-up and had an agent modify his processing repo by monkeypatching processAllTrials_Async to use Kort’s sub-batching strategy. He started reprocessing three SLAP2 sessions that had repeatedly failed. On those machines, he said those sessions normally took about 30 hours to process. The thread does not contain the eventual outcome of those reruns.

SiLO already naturally breaks up solves into subproblems, and runs those subproblems in parallel. The number of subproblems greatly exceeds the number of cores on a single CO node, so we could get to processed data faster by parallelizing across nodes. Could we refactor SiLO to save out the subproblems, and assign them across many workers (embarrassingly parallel) then gather the results, in a pipeline?

Solving 2 seems likely to solve 1 as well.

Lingua principale
MATLAB
Stelle
3
Fork
3
Merge medio
4g 5h
PR unite (30g)
3

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di AllenNeuralDynamics/GIAnT-MATLAB

Tutte le issue di AllenNeuralDynamics/GIAnT-MATLAB

Issue simili

Altre issue su MATLAB

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.