Support needed for VirtualAlloc/VirtualFree analysis
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 28/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- operating-systems, performance
Línea de trabajo
Comienza con bin/VirtualFreeStacks.py y la trace processor library, y después compara la entrada de xperf -a dumper del script con la limitación de WPA descrita en el issue. La tarea está terminada cuando los stacks de VirtualAlloc y VirtualFree se puedan analizar mediante el trace processor sin depender de un análisis de texto frágil.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
VirtualFree and VirtualAlloc stacks can be critical in understanding memory consumption. VirtualFree is particularly interesting for programmatic trace analysis because it cannot be analyzed using WPA - if you just have the free but not the alloc then the data is hidden.
I recently got desperate and wrote code to analyze "xperf -a dumper" output (script is at https://github.com/google/UIforETW/blob/main/bin/VirtualFreeStacks.py). The results were incredibly useful (see crbug.com/1179934) and may help understand a significant memory issue in Chrome and/or Windows, but writing text parsing code to analyze ETW traces seems like the wrong solution at this time.
Text parsing code tends to be more fragile and it also requires additional steps and usually has significantly worse performance than the trace processor library. Text parsing also requires significant investigation in order to understand the layout of the output and what xperf options to use.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 16
- Forks
- 5
- 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 microsoft/eventtracing-processing
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
3E data can not be exportedAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
Todos los issues de microsoft/eventtracing-processing
Issues similares
-
bug(ktuner): exporter directories hide daemon processesPosiblemente ocupada @iloveeyjafjalla la tomó hoy. Abiertocomponent:ktuner
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
agentic-os-org/ANOLISA#6905 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
IO.get_env on Node truncates names at embedded NULPosiblemente ocupada @Yi-111-a la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
HigherOrderCO/Bend#1449 · 1 comentario ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
tenstorrent/ttsim#21 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Host test failure in core/direct_io.zig on Linux kernel 6.17: O_DIRECT open succeeds on procfs, so the test's 'plain' fd is not plainPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ashhart/TensorFold#536 ·
Los mantenedores suelen responder en 1 día