ovis
ovis copied to clipboard
ovis-hpc
remove perfevent and hweventpapi samplers in v4 , master
@valleydlr commented that syspapi sampler and other work has obsoleted perfevent and hweventpapi. If we can all agree about that, these samplers should be removed from the source.
I can't entirely agree with removing the hweventpapi sampler since it can attach to the processes using the "application name" doing ldms_pgrep. At the same time, syspapi depends on the slurm plugin to identify the application PIDs and sometimes, the slurm plugin doesn't exist on the platforms. If we can add this capability to syspapi then we can remove hweventpapi sampler.
Hi @aazizo ,
syspapi collects 'system-wide' hardware event counters. Thus the name. It does not collect job specific data and does not depend on the slurm sampler. The only connection with PAPI is that it uses it to translate event names into HW event codes so that it is easier to write the configuration files. syspapi does not use PAPI to do monitoring at all.
The mt-papi sampler does job-specific monitoring. It subscribes to a stream that identifies what process-id are associated with a job in order to use PAPI to attach to those PID/TID. The provider of that stream could be slurm/spank or any other job scheduler for that matter.
The ldms_pgrep service was created because hweventpapi was using popen with pgrep to try and guess which PID were associated with a job. This broke the RDMA verbs API, and so ldms_pgrep was implemented to avoid fork/exec'ing another process. In the general case, scraping /proc for a cmdline that matches some string is speculative at best.
To be clear, what @valleydlr says is correct. syspapi replaces perfevent, and papi replaces hweventpapi. The benefit of syspapi over perfevent is that you can use the familiar PAPI event codes in your configuration file and it coordinates with the papi sampler to turn itself off if the user wants to use papi, vtune, etc...do application specific hardware event monitoring. The benefit of papi over hweventpapi is that it coordinates with syspapi and it works with the job-scheduler directly to know which PID are part of a job instead of attempting to figure it out by grep'ing /proc