From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: perf code using smp_processor_id() in preemptible [00000000] code
Date: Fri, 15 Nov 2013 16:10:51 +0400 [thread overview]
Message-ID: <20131115121051.GC26143@moon> (raw)
In-Reply-To: <20131115115150.GC10456@twins.programming.kicks-ass.net>
On Fri, Nov 15, 2013 at 12:51:50PM +0100, Peter Zijlstra wrote:
> ok, this will make the error go away, but what about the semantics of
> the case? Does it really matter for the grouping on which cpu we compute
> it? That is can we end up with a different group for one cpu as for
> another?
>
> Or do we simply need a coherent single cpu to do the computation with?
> In which case raw_smp_processor_id() would also suffice.
>
> If we can indeed get a different result depending on which cpu we do the
> computation, then things are broken, because it might be a task group
> we're building which has to be able to migrate around with the task.
The events are sensitive to which cpu they're scheduled to execute on
(if HT is turned on, we need to setup thread bit in register).
As far as I understand once events are assigned to cpu_hw_events
they are executing on this cpu, when tasks are migrated to another
cpu, they're re-scheduled. Or I miss something obvious here?
>
> In that case we must compute the maximal group that can be scheduled on
> all cpus.
>
> This wasn't at all clear.
next prev parent reply other threads:[~2013-11-15 12:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 3:29 perf code using smp_processor_id() in preemptible [00000000] code Dave Jones
2013-11-15 10:02 ` Peter Zijlstra
2013-11-15 10:19 ` Cyrill Gorcunov
2013-11-15 11:30 ` Cyrill Gorcunov
2013-11-15 11:51 ` Peter Zijlstra
2013-11-15 12:10 ` Cyrill Gorcunov [this message]
2013-11-15 12:33 ` Peter Zijlstra
2013-11-15 12:42 ` Cyrill Gorcunov
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=20131115121051.GC26143@moon \
--to=gorcunov@gmail.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).