Open pierrepebay opened 5 months ago
PR tests (gcc-12, ubuntu, mpich, verbose)
Build for 690613eb238542dd5da76fcd00c1f2be1b1f6330 (2024-06-12 19:26:21 UTC)
Build failed for unknown reason. Check build logs
PR tests (gcc-12, ubuntu, mpich, verbose, kokkos)
Build for d65b135b24d5c06c885dc3d81a65851d142a2440 (2024-09-17 13:40:07 UTC)
Compilation - successful
Testing - passed
This branch needs a lot more testing before it is merged. When I put more than 4 items in VT_EVENTS
, I'm seeing memory corruption after the first task collects PAPI events. I'm not sure where in the software stack the problem lies.
This branch needs a lot more testing before it is merged. When I put more than 4 items in
VT_EVENTS
, I'm seeing memory corruption after the first task collects PAPI events. I'm not sure where in the software stack the problem lies.
I also got memory corruption after many tasks when using only 3 items (cache-misses,page-faults,fp_assist.any
). I think this PR still needs work.
Also, this PR unconditionally requires PAPI. We need an option that turns on PAPI support instead of failing configure in all cases where PAPI is not found.
Before this can be merged, it needs to be refactored so that the user interface for perf is very similar to the existing PAPI interface within RunnableNew
. In fact, perf and PAPI should share a single interface in RunnableNew
(so please rename those member functions to not include PAPI
in the name). When perf is chosen at configure time instead of PAPI, the RunnableNew
functions will forward the requests to vt::thePerfData()->startTaskMeasurement()
and the like. Please let me know if this is not clear.
Fixes #2302