All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
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: Tue, 22 Jun 2010 18:26:55 +0200	[thread overview]
Message-ID: <20100622162652.GB5458@nowhere> (raw)
In-Reply-To: <1276845338.27822.1450.camel@twins>

On Fri, Jun 18, 2010 at 09:15:38AM +0200, Peter Zijlstra wrote:
> On Fri, 2010-06-18 at 06:21 +0200, Frederic Weisbecker wrote:
> > 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?
> 
> there still were some users, but yeah, we cuold probably clean that up,
> bit since the patch is large enough as is, I didn't attempt that.


Yeah, that can be done later.


 
> > > +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?
> 
> I wanted to avoid too much trickery, first make a simple one work, then
> try something fancy.



Ok, as far it's not considered a long term thing. I can
improve that from my exclusion patchset, rebased on top of yours.




> > 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.
> 
> You have to track it since we can stop the thing outselves without the
> caller knowing.


>From the pmu internals yeah, that's what the x86 pmu does. But otherwise, other
pmu don't do such things.


  reply	other threads:[~2010-06-22 16:26 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
2010-06-18  7:15     ` Peter Zijlstra
2010-06-22 16:26       ` Frederic Weisbecker [this message]
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=20100622162652.GB5458@nowhere \
    --to=fweisbec@gmail.com \
    --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=peterz@infradead.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.