On Tue, 21 Oct 2014, Peter Zijlstra wrote: > > perf_event is also fairly high overhead for setting up and starting > > events, > > Which you only do once at the start, so is that really a problem?
There are various reasons why you might want to start events at times other than the beginning of the program. Some people don't like kernel multiplexing so they start/stop manually if they want to switch eventsets. But no, I suppose you could ask anyone wanting to use rdpmc to open some sort of dummy event at startup just to get cr4 enabled. > I still don't get that argument, 2 rdpmc's is cheaper than doing wrmsr, > not to mention doing wrmsr through a syscall. And looking at that mmap > page is 1 cacheline. Is that cacheline read (assuming you miss) the real > problem? Well at least by default the first read of the mmap page causes a pagefault which adds a few thousand cycles of latency. Though you can somewhat get around this by prefaulting it in at some point. Anyway I'm just reporting numbers I get when measuring the overhead of the old perfctr interface vs perf_event on typical PAPI workloads. It's true you can re-arrange calls and such so that perf_event behaves better but that involves redoing a lot of existing code. I do appreciate the trouble you've gone through keeping self-monitoring working considering the fact that I'm the only user admitting to using it. Adding perf_event rdpmc support to PAPI has been stalled for a while due to various reasons. So that's why I haven't been finding the various bugs that have been turning up. The PAPI perf_event component really needs a complete from-scratch re-write, but that's made tricky because we have to be backwards compatible and workaround all the pre-2.6.36 perf_event bugs. You wouldn't think anyone would care, but the most vocal users are all RHEL 6 users running the monstrosity of a 2.6.32 kernel that is patched full of all kinds of crazy back-ported perf_event patches, and that is always breaking PAPI in fun and exciting ways. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/