On 12/08/2011 11:07 PM, Vince Weaver wrote: > On Fri, 12 Aug 2011, Ryan Johnson wrote: >> Are there plans to enable the kernel support that perf events seems to >> assume already exists? > the libpfm4 tests are likely based on the libpfm3/perfmon2 code. The > perfmon2 kernel patches allowed rdpmc as far as I know. Bitten by wheel-reinventing? /usr/include/linux/perf_event.h suggests essentially identical code as The Right Way to use mmapped events (see the comment inside perf_event_mmap_page).
> If you want rdpmc in a perf_event kernel you're going to have to bug the > perf_event developers on the linux-kernel list. At least one of them > wasn't against the idea, but I'm sure it's a pretty low priority for them. I'd be happy to hack on some code a bit... the perfctr patches are pretty straightforward... but I'm not familiar with the kernel and can't tell at all by looking at the perf_events code whether the perfctr way of doing things makes sense even as a private hack. I'm almost tempted to just write a small kernel module that enables rdpmc unilaterally for a pid... You had mentioned it was on your todo list; if you could share your high-level idea of what you would have done that would give me a huge head start in putting a patch together. > Is what you're doing timing critical enough that having a read() syscall > instead is just too much? I'm interested in L2 and LLC misses, and syscalls have a tendency to clobber caches. Even if the kernel-side misses caused by a syscall aren't counted directly, userspace will suffer (and count) more misses later because of it. Off-topic: I really can't figure out how linux devs decide which features to reject... microstate accounting patches were utterly dismissed due to their potential performance impact, even though they have a huge impact on system observability, but taking HW counter zero away from the watchdog is verboten because it creates better dumps when the kernel dies an ugly death. > There are issues involved with rdpmc, such as > what to do if the events you've selected are multiplexing, etc. If they don't want people to use rdpmc (e.g. no architectural support, unimplemented feature, multiplexing complications, or for security reasons), they could at least be polite enough to set index=-1. Right now the test case works, often calling read() several times... until the kernel initializes the mmapped page and tricks it into attempting rdpmc. I hesitate to bring that up, tho, because they'd probably just unilaterally set index=-1 and never look at it again... Ryan ------------------------------------------------------------------------------ FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
