Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 20 Oct 2014 21:28:29 -0700 | Subject | Re: [RFC 0/5] CR4 handling improvements |
| |
On Mon, Oct 20, 2014 at 9:06 PM, Vince Weaver <vince@deater.net> wrote: > On Tue, 14 Oct 2014, Andy Lutomirski wrote: > >> This little series tightens up rdpmc permissions. With it applied, >> rdpmc can only be used if a perf_event is actually mmapped. For now, >> this is only really useful for seccomp. > > So just to be difficult... > > I am aware of at least one group who is doing low-latency performance > measures using rdpmc on Linux. > > They start the counters manually by poking the MSRs directly (bypassing > perf_event_open()). > > They use rdpmc, grateful for the fact that currently CR4 is set up so they > can do this w/o patching the kernel. > > These patches of course would break this use case...
ISTM it would be a lot better to use the perf subsystem for this. You can probably pin an event to a pmu. I don't know whether you can pin an event systemwide. I also don't know whether pinning an event will prevent perf from changing its value periodically, and it certainly doesn't magically make wraparound issues go away.
It would be easy to add a new setting for rdpmc to deal with the PCE part.
E.g. rdpmc = 2 could allow all tasks to use rdpmc regardless of whether they have an event mapped. (And I would have to re-add the static key. Sigh.)
--Andy
P.S. Hey, Intel, you forgot to add rdpmcp :-/
| |