From: Roger Quadros <rogerq@ti.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: khilman@deeprootsystems.com, tony@atomide.com,
linux-omap@vger.kernel.org, jean.pihet@newoldbits.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Date: Tue, 11 Sep 2012 11:29:06 +0300 [thread overview]
Message-ID: <504EF652.2020302@ti.com> (raw)
In-Reply-To: <504E2921.50408@codeaurora.org>
On 09/10/2012 08:53 PM, Stephen Boyd wrote:
> On 09/10/12 04:30, Roger Quadros wrote:
>> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>>
>> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
>> [ 28.832946] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/1763
>> [ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
>>
>> changes in v2:
>> - rebased on 3.6-rc5
>> - use put_cpu() immediately after get_cpu() in omap3_pm_idle()
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> arch/arm/mach-omap2/clock.c | 9 ++++++---
>> arch/arm/mach-omap2/pm34xx.c | 12 ++++++++----
>> arch/arm/mach-omap2/powerdomain.c | 6 ++++--
>> 3 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index ea3f565..06747b6 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
>> @@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
>> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>>
>> if (clk->ops && clk->ops->disable) {
>> - trace_clock_disable(clk->name, 0, smp_processor_id());
>> + trace_clock_disable(clk->name, 0, get_cpu());
>> + put_cpu();
>
> Why are you doing this? Why not just use raw_smp_processor_id()? Do you
> really care about the CPU number? get_cpu() and put_cpu() are about
> non-preemptible sections where you want to ensure the CPU the code is
> operating on is actually on that CPU.
You are right. raw_smp_processor_id() makes perfect sense here.
>
> How about just put 0 all the time because the CPU number is already part
> of the trace event?
>
I'm not sure about this. I can see that removing the cpu_id field from
trace_cpu_idle() was discussed here [1] and it was decided to keep it.
There was no conclusion about removing it from
trace_clock_enable/disable though.
For now, I will resend the patch with raw_smp_processor_id().
regards,
-roger
[1] https://lkml.org/lkml/2011/8/19/316
WARNING: multiple messages have this Message-ID (diff)
From: rogerq@ti.com (Roger Quadros)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id
Date: Tue, 11 Sep 2012 11:29:06 +0300 [thread overview]
Message-ID: <504EF652.2020302@ti.com> (raw)
In-Reply-To: <504E2921.50408@codeaurora.org>
On 09/10/2012 08:53 PM, Stephen Boyd wrote:
> On 09/10/12 04:30, Roger Quadros wrote:
>> gets rid of below messages with CONFIG_DEBUG_PREEMPT enabled
>>
>> [ 28.832916] debug_smp_processor_id: 18 callbacks suppressed
>> [ 28.832946] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/1763
>> [ 28.841491] caller is pwrdm_set_next_pwrst+0x54/0x120
>>
>> changes in v2:
>> - rebased on 3.6-rc5
>> - use put_cpu() immediately after get_cpu() in omap3_pm_idle()
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> arch/arm/mach-omap2/clock.c | 9 ++++++---
>> arch/arm/mach-omap2/pm34xx.c | 12 ++++++++----
>> arch/arm/mach-omap2/powerdomain.c | 6 ++++--
>> 3 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
>> index ea3f565..06747b6 100644
>> --- a/arch/arm/mach-omap2/clock.c
>> +++ b/arch/arm/mach-omap2/clock.c
>> @@ -285,7 +285,8 @@ void omap2_clk_disable(struct clk *clk)
>> pr_debug("clock: %s: disabling in hardware\n", clk->name);
>>
>> if (clk->ops && clk->ops->disable) {
>> - trace_clock_disable(clk->name, 0, smp_processor_id());
>> + trace_clock_disable(clk->name, 0, get_cpu());
>> + put_cpu();
>
> Why are you doing this? Why not just use raw_smp_processor_id()? Do you
> really care about the CPU number? get_cpu() and put_cpu() are about
> non-preemptible sections where you want to ensure the CPU the code is
> operating on is actually on that CPU.
You are right. raw_smp_processor_id() makes perfect sense here.
>
> How about just put 0 all the time because the CPU number is already part
> of the trace event?
>
I'm not sure about this. I can see that removing the cpu_id field from
trace_cpu_idle() was discussed here [1] and it was decided to keep it.
There was no conclusion about removing it from
trace_clock_enable/disable though.
For now, I will resend the patch with raw_smp_processor_id().
regards,
-roger
[1] https://lkml.org/lkml/2011/8/19/316
next prev parent reply other threads:[~2012-09-11 8:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 11:30 [PATCH v2] perf: Use pre-empt safe cpu_get/put insted of smp_processor_id Roger Quadros
2012-09-10 11:30 ` Roger Quadros
2012-09-10 16:54 ` Kevin Hilman
2012-09-10 16:54 ` Kevin Hilman
2012-09-10 17:53 ` Stephen Boyd
2012-09-10 17:53 ` Stephen Boyd
2012-09-11 8:29 ` Roger Quadros [this message]
2012-09-11 8:29 ` Roger Quadros
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=504EF652.2020302@ti.com \
--to=rogerq@ti.com \
--cc=jean.pihet@newoldbits.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=sboyd@codeaurora.org \
--cc=tony@atomide.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.