Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

don't use fast rdpmc counter reads in attach or syswide scenarios #39

Merged
merged 1 commit into from
Jul 3, 2023
Merged

don't use fast rdpmc counter reads in attach or syswide scenarios #39

merged 1 commit into from
Jul 3, 2023

Commits on Jul 3, 2023

  1. don't use fast rdpmc counter reads in attach or syswide scenarios 

    With perf_event we can use fast rdpmc reads for low-overhead counter
access.  This only works in self-monitoring situations where the
thread being measured is in the same process context and same CPU
as PAPI.  This means it cannot generally be used in the attach
case, or if trying to do system-wide measurements (granularity
anything other than PAPI_GRN_THR).

Ideally the Linux kernel would notice the request to use rdpmc in
inappropriate circumstances and cause the mmap() read to fail and
fallback to using the read() syscall.  However for various reasons
the kernel devs did not want to support this, so it's up to PAPI
to avoid using rdpmc in cases where Linux will silently fail and
allow rdpmc to return invalid counter values.

This should fix the "attach_cpu_sys_validate" test failure.
    @deater @gcongiu
    deater authored and gcongiu committed Jul 3, 2023
    Configuration menu
    Copy the full SHA
    4f63dfe View commit details
    Browse the repository at this point in the history