From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"mingo@elte.hu" <mingo@elte.hu>, Andi Kleen <andi@firstfloor.org>,
Lin Ming <ming.m.lin@intel.com>
Subject: Re: [PATCH 2/3] perf_events: fix validation of events using an extra reg (v4)
Date: Tue, 21 Jun 2011 13:37:56 +0200 [thread overview]
Message-ID: <1308656276.26237.130.camel@twins> (raw)
In-Reply-To: <BANLkTi=-rfp8qrh4-u7wtnq7e0PkFTNwxA@mail.gmail.com>
On Tue, 2011-06-21 at 11:54 +0200, Stephane Eranian wrote:
> On Thu, Jun 9, 2011 at 10:48 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, 2011-06-09 at 22:36 +0200, Stephane Eranian wrote:
> >> On Thu, Jun 9, 2011 at 8:40 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> >> > On Mon, 2011-06-06 at 16:57 +0200, Stephane Eranian wrote:
> >> >> +static struct cpu_hw_events *allocate_fake_cpuc(void)
> >> >> +{
> >> >> + struct cpu_hw_events *cpuc;
> >> >> + int cpu = smp_processor_id();
> >> >
> >> > That's a boo-boo, clearly we are in a preemptible context here (see the
> >> > GFP_KERNEL allocation on the next line), so using smp_processor_id()
> >> > isn't valid.
> >> >
> >> Good point. I missed that.
> >
> > Yeah, I did too, Ingo found it during testing.
> >
> >> > Now since all that allocate_shared_regs() does with it is pick a NUMA
> >> > node, we should probably use raw_smp_processor_id() and leave it at
> >> > that, right?
> >> >
> Looked at that some more. It is more subtle than this.
> allocate_shared_regs() is used in two places:
> - allocate_fake_cpuc()
> - intel_pmu_cpu_prepare()
>
> In the first case, it does not matter where the cpuc is allocated,
> it's not on any
> critical path. But for the other situation, it'd better be allocated
> on the cpu node.
> But I think that is what we get given it is called during the CPU
> hotplug prepare
> path, so it must be running on the CPU to prepare and thus a kzalloc() should
> allocate on the right node, right?
Yeah. Let me shove these patches mingo wards again.
next prev parent reply other threads:[~2011-06-21 11:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 14:57 [PATCH 2/3] perf_events: fix validation of events using an extra reg (v4) Stephane Eranian
2011-06-09 18:40 ` Peter Zijlstra
2011-06-09 20:36 ` Stephane Eranian
2011-06-09 20:48 ` Peter Zijlstra
2011-06-21 9:54 ` Stephane Eranian
2011-06-21 11:37 ` Peter Zijlstra [this message]
2011-07-01 15:22 ` [tip:perf/core] perf_events: Fix validation of events using an extra reg tip-bot for Stephane Eranian
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=1308656276.26237.130.camel@twins \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
/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.