On Thu, 28 Aug 2014, Gary Mohr wrote:
> Given this sequence of events, I understand why neither PAPI or libpfm4
> detected that these events cannot be used at the same time. But it seems to
> me like the kernel should have been able to detect this when the second
> event was opened and return an error. This would have been a much better
> time to report the error than when trying to read the results of an event
> that the kernel said was successfully opened.
This is a long-standing issue with the linux-kernel interface, though
I have to admit I've only seen it when dealing with general purpose
counters when the watchdog is enabled (i.e., when the kernel has stolen a
performance counter for its own use).
I've complained about this off and on to the kernel developers for years
without much luck, I think the consensus was it would be too much work
to report a proper error.
I do find it odd that this error is cropping up in the uncore and RAPL
pmus though, it might be a different error path that can be fixed more
easily.
> Is there a way that PAPI or libpfm4 could have detected this invalid
> combination of events before doing the kernel opens ?
PAPI currently works around this problem in the perf_event component by,
at event add time, doing a quick perf_event_open()/read()/close() sequence
to see if the event is in fact valid. This adds overhead, but it's the
only reliable way of telling if an event is actually valid.
I probably dropped this extra check in the uncore component thinking it
was unnecessary, it could be added back in.
Vince
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
