From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
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 3/8] perf: register pmu implementations
Date: Wed, 16 Jun 2010 19:48:00 +0200 [thread overview]
Message-ID: <1276710480.1745.608.camel@laptop> (raw)
In-Reply-To: <20100616170354.GA5530@nowhere>
On Wed, 2010-06-16 at 19:03 +0200, Frederic Weisbecker wrote:
> > +static struct pmu perf_breakpoint = {
> > + .event_init = hw_breakpoint_event_init,
>
>
>
> Should be bp_perf_event_init?
Ah, yes, like said, the compiler didn't get near yet..
>
> > + .enable = arch_install_hw_breakpoint,
> > + .disable = arch_uninstall_hw_breakpoint,
> > + .read = hw_breakpoint_pmu_read,
> > +};
> <snip>
> > +static int perf_swevent_int(struct perf_event *event)
> > +{
> > + if (event->attr.type != PERF_TYPE_SOFTWARE)
> > + return -ENOENT
>
>
> perf_swevent_init() ?
copy/paste gone wild..
> > +void perf_pmu_unregister(struct pmu *pmu)
> > +{
> > + spin_lock(&pmus_lock);
> > + list_del_rcu(&pmu->entry);
> > + spin_unlock(&pmus_lock);
> > +
> > + synchronize_srcu(&pmus_srcu);
> > +}
> Who needs this?
Nobody yet..
> > +
> > +struct pmu *perf_init_event(struct perf_event *event)
> > +{
> > + struct pmu *pmu;
> > + int idx;
> > +
> > + idx = srcu_read_lock(&pmus_srcu);
> > + list_for_each_entry_rcu(pmu, &pmus, entry) {
> > + int ret = pmu->event_init(event);
> > + if (!ret)
> > + break;
> > + if (ret != -ENOENT) {
> > + pmu = ERR_PTR(ret);
> > + break;
> > }
> > - pmu = &perf_ops_generic;
> > - break;
> > }
> > + srcu_read_unlock(&pmus_srcu, idx);
>
>
>
> This could use a simple mutex instead of a spinlock + srcu_sync on
> writer and srcu on reader.
Right, that spinlock needs to be a mutex for sure, a later patch adds an
allocation under it.
But even with a mutex we need srcu_sync in there to sync against the
readers.
> That doesn't matter much that said. What I don't understand is
> why we need to synchronize the writers. Walking the list with
> list_*_rcu() looks justified once we support boot events, but
> until then...
Well, the typical unregister user would be a module, if you unregister
and then dealloc the struct pmu by unloading the module a reader might
still see a reference to it if you don't srcu_sync it.
next prev parent reply other threads:[~2010-06-16 17:48 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 [this message]
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
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=1276710480.1745.608.camel@laptop \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=dengcheng.zhu@gmail.com \
--cc=eranian@googlemail.com \
--cc=fweisbec@gmail.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.