Re: [RFC 0/5] CR4 handling improvements

[Vince Weaver]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/