[lkml]   [2014]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 0/5] CR4 handling improvements
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.


 \ /
  Last update: 2014-10-21 19:41    [W:0.096 / U:5.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site