From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
mingo@redhat.com, Paul Mackerras <paulus@samba.org>,
dev@codyps.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 4/5] perf: Define PMU_TXN_READ interface
Date: Thu, 9 Apr 2015 12:10:29 -0700 [thread overview]
Message-ID: <20150409191029.GA29855@us.ibm.com> (raw)
In-Reply-To: <20150408124535.GF23123@twins.programming.kicks-ass.net>
Peter Zijlstra [peterz@infradead.org] wrote:
| On Tue, Apr 07, 2015 at 05:34:58PM -0700, Sukadev Bhattiprolu wrote:
| > diff --git a/kernel/events/core.c b/kernel/events/core.c
| > index 1ac99d1..a001582 100644
| > --- a/kernel/events/core.c
| > +++ b/kernel/events/core.c
| > @@ -3644,6 +3644,33 @@ static void orphans_remove_work(struct work_struct *work)
| > put_ctx(ctx);
| > }
| >
| > +/*
| > + * Use the transaction interface to read the group of events in @leader.
| > + * PMUs like the 24x7 counters in Power, can use this to queue the events
| > + * in the ->read() operation and perform the actual read in ->commit_txn.
| > + *
| > + * Other PMUs can ignore the ->start_txn and ->commit_txn and read each
| > + * PMU directly in the ->read() operation.
| > + */
| > +static int perf_event_read_txn(struct perf_event *leader)
|
| perf_event_read_group() might be a better name. Ah, I see that's already
| taken. Bugger.
|
| See the below patch.
Sure, will include your patch in the next version and use
perf_event_read_group().
|
| > +{
| > + int ret;
| > + struct perf_event *sub;
| > + struct pmu *pmu;
| > +
| > + pmu = leader->pmu;
| > +
| > + pmu->start_txn(pmu, PERF_PMU_TXN_READ);
| > +
| > + perf_event_read(leader);
| > + list_for_each_entry(sub, &leader->sibling_list, group_entry)
| > + perf_event_read(sub);
| > +
| > + ret = pmu->commit_txn(pmu, PERF_PMU_TXN_READ);
| > +
| > + return ret;
| > +}
|
| And while were here, should we change the NOP txn implementation to not
| call perf_pmu_disable for TXN_READ ?
|
| That seems entirely unneeded in this case.
Yes. Should we use a per-cpu, per-pmu variable to save/check the
transaction type like this? (I am using the cpuhw->group_flag in
x86, Power and other PMUs)
>From 2f3658b0b131739dc08e0d6d579e58864d1777bc Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Thu, 9 Apr 2015 13:47:50 -0400
Subject: [PATCH 1/1] perf: Have NOP txn interface ignore non ADD txns
The NOP txn interface should ignore non TXN_ADD transactions and
avoid disabling/enabling the PMU.
Use a per-cpu, per-PMU flag to store/check the type of transaction
in progress.
Thanks to Peter Zijlstra for the input.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9e869b2..9466864 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -160,7 +160,10 @@ struct perf_event;
/*
* Common implementation detail of pmu::{start,commit,cancel}_txn
*/
-#define PERF_EVENT_TXN 0x1
+#define PERF_EVENT_TXN_ADD 0x1 /* txn to add/schedule event on PMU */
+#define PERF_EVENT_TXN_READ 0x2 /* txn to add/schedule event on PMU */
+
+#define PERF_EVENT_TXN_MASK (PERF_EVENT_TXN_ADD|PERF_EVENT_TXN_READ)
/**
* pmu::capabilities flags
@@ -240,8 +243,10 @@ struct pmu {
*
* Start the transaction, after this ->add() doesn't need to
* do schedulability tests.
+ *
+ * Optional.
*/
- void (*start_txn) (struct pmu *pmu); /* optional */
+ void (*start_txn) (struct pmu *pmu, int flags);
/*
* If ->start_txn() disabled the ->add() schedulability test
* then ->commit_txn() is required to perform one. On success
@@ -534,6 +534,7 @@ struct perf_cpu_context {
ktime_t hrtimer_interval;
struct pmu *unique_pmu;
struct perf_cgroup *cgrp;
+ int group_flag;
};
struct perf_output_handle {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0ebc468..08d0c3e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6746,18 +6746,35 @@ static int perf_pmu_nop_int(struct pmu *pmu)
static void perf_pmu_start_txn(struct pmu *pmu, int flags)
{
- perf_pmu_disable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
+
+ BUG_ON(cpuctx->group_flag);
+
+ cpuctx->group_flag = flags;
+
+ if (flags & PERF_EVENT_TXN_ADD)
+ perf_pmu_disable(pmu);
}
static int perf_pmu_commit_txn(struct pmu *pmu)
{
- perf_pmu_enable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
+
+ if (cpuctx->group_flag & PERF_EVENT_TXN_ADD)
+ perf_pmu_enable(pmu);
+
+ cpuctx->group_flag &= ~PERF_EVENT_TXN_MASK;
return 0;
}
static void perf_pmu_cancel_txn(struct pmu *pmu)
{
- perf_pmu_enable(pmu);
+ struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
+
+ if (cpuctx->group_flag & PERF_EVENT_TXN_ADD)
+ perf_pmu_enable(pmu);
+
+ cpuctx->group_flag &= ~PERF_EVENT_TXN_MASK;
}
static int perf_event_idx_default(struct perf_event *event)
next prev parent reply other threads:[~2015-04-16 17:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 0:34 [PATCH v2 0/5] perf: Implement event group read using txn interface Sukadev Bhattiprolu
2015-04-08 0:34 ` [PATCH v2 1/5] perf: Add a flags parameter to pmu txn interfaces Sukadev Bhattiprolu
2015-04-08 12:19 ` Peter Zijlstra
2015-04-08 15:40 ` Sukadev Bhattiprolu
2015-04-08 0:34 ` [PATCH v2 2/5] perf: Split perf_event_read() and perf_event_count() Sukadev Bhattiprolu
2015-04-08 0:34 ` [PATCH v2 3/5] perf: Rename perf_event_read_value Sukadev Bhattiprolu
2015-04-08 12:24 ` Peter Zijlstra
2015-04-08 0:34 ` [PATCH v2 4/5] perf: Define PMU_TXN_READ interface Sukadev Bhattiprolu
2015-04-08 12:45 ` Peter Zijlstra
2015-04-09 19:10 ` Sukadev Bhattiprolu [this message]
2015-04-08 0:34 ` [PATCH v2 5/5] powerpc/perf/hv-24x7: Use " Sukadev Bhattiprolu
2015-04-08 12:51 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150409191029.GA29855@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=acme@kernel.org \
--cc=dev@codyps.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).