Parallelize subproblem solves in SiLO/address memory leak on Linux

Abierto
  • ¿Algo no está bien?
#21 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Área
data

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
MATLAB
Estrellas
3
Forks
2
Merge medio
4 d 5 h
PR fusionados (30 d)
3

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de AllenNeuralDynamics/GIAnT-MATLAB

Todos los issues de AllenNeuralDynamics/GIAnT-MATLAB

Issues similares

Más issues de MATLAB

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.