[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1410211057120.1451@pianoman.cluster.toy>
Date: Tue, 21 Oct 2014 11:00:26 -0400 (EDT)
From: Vince Weaver <vince@...ter.net>
To: Andy Lutomirski <luto@...capital.net>
cc: Peter Zijlstra <peterz@...radead.org>,
Valdis Kletnieks <Valdis.Kletnieks@...edu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Kees Cook <keescook@...omium.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Erik Bosman <ebn310@....vu.nl>
Subject: Re: [RFC 0/5] CR4 handling improvements
On Mon, 20 Oct 2014, Andy Lutomirski wrote:
> ISTM it would be a lot better to use the perf subsystem for this. You
> can probably pin an event to a pmu.
No, you cannot pin an event to a counter with perf_event.
That's one of the big differences between perf_event and, say, perfmon2.
With perf_event the kernel controls which events go in which counters and
the user has no say. That's part of why you need to check the mmap page
every time you want to use rdpmc because there's no other way of knowing
which counter to read to get the event you want.
perf_event is also fairly high overhead for setting up and starting
events, and mildly high overhead when doing a proper rdpmc call (due to
the required looking at mmap, and the fact that you need to do two rdpmc
calls before/after to get your value). This is why people really worried
about low-latency measurements bypass as much of perf_event as possible.
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists