From: Robert Richter <robert.richter@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: paulus <paulus@samba.org>,
stephane eranian <eranian@googlemail.com>,
Will Deacon <will.deacon@arm.com>,
Paul Mundt <lethal@linux-sh.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: perf_disable()
Date: Fri, 11 Jun 2010 18:52:23 +0200 [thread overview]
Message-ID: <20100611165223.GO21799@erda.amd.com> (raw)
In-Reply-To: <1276273784.2077.2055.camel@twins>
On 11.06.10 12:29:44, Peter Zijlstra wrote:
> I've been going over perf_disable() usage in kernel/perf_event.c and
> wondered if we actually need it at all.
>
> Currently the only thing we seem to require it for is around pmu::enable
> calls (and for that powerpc at least does it itself, on x86 we rely on
> it to call ->enable_all and reprogram the pmu state).
>
> But I can't really find any NMI races wrt data structures or the like as
> seems implied by some comments.
Yes, it was originally used to disable nmis for some critical sections
in the non-arch code. I do not remember where this was exactly needed,
but my feeling is also this can be optimized and maybe reimplemented
as non-locking code.
We also should avoid the enable_all/disable_all() functions in the x86
implementation as it is expensive on some pmus (namely AMD). It looks
like these functions can be removed then too, or at least made model
specific only.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
next prev parent reply other threads:[~2010-06-11 16:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-11 16:29 perf_disable() Peter Zijlstra
2010-06-11 16:52 ` Robert Richter [this message]
2010-06-11 17:17 ` perf_disable() Frederic Weisbecker
2010-06-11 20:29 ` perf_disable() Peter Zijlstra
2010-06-11 21:01 ` perf_disable() Frederic Weisbecker
2010-06-11 21:04 ` perf_disable() Frederic Weisbecker
2010-06-11 21:25 ` perf_disable() Peter Zijlstra
2010-06-14 9:23 ` perf_disable() Will Deacon
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=20100611165223.GO21799@erda.amd.com \
--to=robert.richter@amd.com \
--cc=eranian@googlemail.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox