From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: paulus <paulus@samba.org>,
stephane eranian <eranian@googlemail.com>,
Robert Richter <robert.richter@amd.com>,
Will Deacon <will.deacon@arm.com>,
Paul Mundt <lethal@linux-sh.org>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Lin Ming <ming.m.lin@intel.com>,
Yanmin <yanmin_zhang@linux.intel.com>,
Deng-Cheng Zhu <dengcheng.zhu@gmail.com>,
David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 8/8] perf: Rework the PMU methods
Date: Fri, 18 Jun 2010 06:21:44 +0200 [thread overview]
Message-ID: <20100618042143.GE5345@nowhere> (raw)
In-Reply-To: <20100616160238.721536975@chello.nl>
On Wed, Jun 16, 2010 at 06:00:35PM +0200, Peter Zijlstra wrote:
> -static void x86_pmu_stop(struct perf_event *event)
> +static void x86_pmu_stop(struct perf_event *event, int flags)
> {
> - struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
> - struct hw_perf_event *hwc = &event->hw;
> - int idx = hwc->idx;
> -
> if (!__test_and_clear_bit(idx, cpuc->active_mask))
> - return;
Do you still need active_mask now that you have HES_STOPPED?
> @@ -4069,6 +4051,9 @@ static int perf_swevent_match(struct per
> struct perf_sample_data *data,
> struct pt_regs *regs)
> {
> + if (event->hw.state)
> + return 0;
> +
> if (event->attr.type != type)
> return 0;
>
> @@ -4211,7 +4196,7 @@ static void perf_swevent_read(struct per
> {
> }
>
> -static int perf_swevent_enable(struct perf_event *event)
> +static int perf_swevent_add(struct perf_event *event, int flags)
> {
> struct hw_perf_event *hwc = &event->hw;
> struct perf_cpu_context *cpuctx;
> @@ -4224,6 +4209,8 @@ static int perf_swevent_enable(struct pe
> perf_swevent_set_period(event);
> }
>
> + hwc->state = !(flags & PERF_EF_START);
> +
> head = find_swevent_head(cpuctx, event);
> if (WARN_ON_ONCE(!head))
> return -EINVAL;
> @@ -4233,13 +4220,19 @@ static int perf_swevent_enable(struct pe
> return 0;
> }
>
> -static void perf_swevent_disable(struct perf_event *event)
> +static void perf_swevent_del(struct perf_event *event, int flags)
> {
> hlist_del_rcu(&event->hlist_entry);
> }
>
> -static void perf_swevent_void(struct perf_event *event)
> +static void perf_swevent_start(struct perf_event *event, int flags)
> +{
> + event->hw.state = 0;
> +}
> +
> +static void perf_swevent_stop(struct perf_event *event, int flags)
> {
> + event->hw.state = 1;
> }
So, instead of doing this and add yet another check in the fast path,
what about just playing with the hlist insertion and deletion?
And if we have PERF_EF_RELOAD in start or PERF_EF_UPDATE in stop,
we simply do nothing, as we know it's just about updating the counter
or reset the interrupt, things that software events just don't care.
And in ->add, you can also do nothing if PERF_EF_START.
It would be nice to have a PERF_EF_STOP as well in ->del, so that
each pmu don't need to maintain an internal state.
If we assume the generic code will never imbalance add/start/stop/del,
or call start after add(PERF_EF_START), or things like this, pmus
like this don't need to ever touch event->hw.state. It's only
necessary for hardware events that call their start/stop internally.
> static inline void perf_tp_register(void)
> @@ -4546,7 +4537,7 @@ void perf_bp_event(struct perf_event *bp
>
> perf_sample_data_init(&sample, bp->attr.bp_addr);
>
> - if (!perf_exclude_event(bp, regs))
> + if (!bp->hw.state && !perf_exclude_event(bp, regs))
> perf_swevent_add(bp, 1, 1, &sample, regs);
Same thing here, and same for trace events.
> }
> #endif
> @@ -4591,12 +4582,12 @@ static void perf_swevent_start_hrtimer(s
> if (hwc->sample_period) {
> u64 period;
>
> - if (hwc->remaining) {
> - if (hwc->remaining < 0)
> + if (hwc->period_left) {
> + if (hwc->period_left < 0)
> period = 10000;
> else
> - period = hwc->remaining;
> - hwc->remaining = 0;
> + period = hwc->period_left;
> + hwc->period_left = 0;
If remaining can be replaced by period_left, it should probably be done
in another patch.
next prev parent reply other threads:[~2010-06-18 4:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 16:00 [RFC][PATCH 0/8] perf pmu interface Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 1/8] perf, x86: Fix Nehalem PMU quirk Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 2/8] perf: deconstify struct pmu Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 3/8] perf: register pmu implementations Peter Zijlstra
2010-06-16 16:45 ` Robert Richter
2010-06-16 17:03 ` Frederic Weisbecker
2010-06-16 17:48 ` Peter Zijlstra
2010-06-16 18:10 ` Peter Zijlstra
2010-06-18 4:51 ` Frederic Weisbecker
2010-06-17 23:31 ` Paul Mackerras
2010-06-18 8:40 ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 4/8] perf: Unindent labels Peter Zijlstra
2010-06-16 17:16 ` Frederic Weisbecker
2010-06-16 17:48 ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 5/8] perf: Reduce perf_disable() usage Peter Zijlstra
2010-06-16 16:52 ` Cyrill Gorcunov
2010-06-16 16:00 ` [RFC][PATCH 6/8] perf: Per PMU disable Peter Zijlstra
2010-06-16 17:48 ` Robert Richter
2010-06-16 17:58 ` Peter Zijlstra
2010-06-18 2:14 ` Frederic Weisbecker
2010-06-18 7:11 ` Peter Zijlstra
2010-06-22 16:21 ` Frederic Weisbecker
2010-06-22 17:09 ` Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 7/8] perf: Default PMU ops Peter Zijlstra
2010-06-16 16:00 ` [RFC][PATCH 8/8] perf: Rework the PMU methods Peter Zijlstra
2010-06-18 4:21 ` Frederic Weisbecker [this message]
2010-06-18 7:15 ` Peter Zijlstra
2010-06-22 16:26 ` Frederic Weisbecker
2010-06-22 17:10 ` Peter Zijlstra
2010-06-16 18:19 ` [RFC][PATCH 0/8] perf pmu interface Peter Zijlstra
2010-06-18 4:35 ` Frederic Weisbecker
2010-06-18 7:22 ` 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=20100618042143.GE5345@nowhere \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=davem@davemloft.net \
--cc=dengcheng.zhu@gmail.com \
--cc=eranian@googlemail.com \
--cc=gorcunov@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=will.deacon@arm.com \
--cc=yanmin_zhang@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.