All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.