[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPoQQ-3UW4WsUEE1a_ApkuJUEZFSYK+p78377DtcPRPFq3qrqQ@mail.gmail.com>
Date: Sun, 22 Feb 2015 16:04:48 -0500
From: Cody P Schafer <dev@...yps.com>
To: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>,
Anton Blanchard <anton@....ibm.com>,
Stephane Eranian <eranian@...gle.com>,
Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] perf: Implement read_group() PMU operation
On Thu, Feb 5, 2015 at 9:59 PM, Sukadev Bhattiprolu
<sukadev@...ux.vnet.ibm.com> wrote:
> From: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
> Date: Thu Feb 5 20:56:20 EST 2015 -0300
> Subject: [RFC][PATCH] perf: Implement read_group() PMU operation
>
> This is a lightly tested, exploratory patch to allow PMUs to return
> several counters at once. Appreciate any comments :-)
>
Back when I was fiddling with this, I started looking into changing
the {start,commit,cancel}_txn to operate on (struct perf_event *)
rather than (struct pmu *), and commit_txn would generate the actual
request & reads based on the perf_event's group (sounds similar but
not identical to what Peter's proposed previously).
The key bit I was concerned about was that these "PMUs" aren't
actually physical hw, so it made a bit more sense to pin the grouping
to a group rather than a txn over a PMU.
[Of course, I never did confirm if that actually fit with how perf was
modeling txns]
--
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