linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: paulmck@linux.vnet.ibm.com, Dipankar Sarma <dipankar@in.ibm.com>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [v3.10-rc1] WARNING: at kernel/rcutree.c:502
Date: Tue, 14 May 2013 13:16:55 +0530	[thread overview]
Message-ID: <5191EBEF.4060409@linux.vnet.ibm.com> (raw)
In-Reply-To: <87ppwuroxb.fsf@nemi.mork.no>

On 05/14/2013 01:08 PM, Bjørn Mork wrote:
> "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> writes:
>> On 05/13/2013 08:09 PM, Bjørn Mork wrote:
>>
>>> Hey, hey, hey.  Turns out this wasn't that wrong after all.  That merge
>>> includes a oneline diff in kernel/cpu/idle.c and it *is* actually this
>>> diff which trigger the problem for me.  Reverting it, using the attached
>>> patch, makes the warning go away.  Which means that it had nothing to do
>>> with your RCU changes.
>>>
>>> But I haven't the faintest idea how this is supposed to work, or even
>>> how to explain the patch properly, so I think I need some help from
>>> Thomas here.  Unless this makes you understand the real issue?
>>>
>>> Thomas, why does powertop trigger the
>>>
>>>   WARNING: at kernel/rcutree.c:502 rcu_eqs_exit_common.isra.48+0x3d/0x125()
>>>
>>> without the attached patch?  And what is the proper resolution?
>>>
>>  
>> The problem appears to be in the cpu idle poll implementation. You can trigger
>> this problem by passing idle=poll in the kernel cmd-line as well, right?
> 
> That sounded so obvious that it made me think "Doh, why didn't I just
> test that before?"  But unfortunately there must be some other factor
> involved. No warnings observed during normal use when running with
> idle=poll:
> 

I didn't expect warnings with normal use.

>  bjorn@nemi:~$ dmesg|grep polling
>  [    0.000000] process: using polling idle threads
> 
> 
> I expected a flood of warnings here, but there is none until I start
> powertop (to confirm that the original issue is still there).  So it's
> more than just entering cpu_idle_poll().
>

Yeah, of course it is :-) The warning triggers only when you enable the tracepoint
in the idle code. And in your case, powertop does that. That's why it only
triggers when you run powertop. Alternatively, if you enable the tracepoint
yourself manually, I bet you'll see the warnings, even without using powertop.
 
>> I think I understand what is going on here. Can you please try the fix below?
>> (It is only compile-tested since its very late here and I really need to get
>> some sleep!).
> 
> Works perfect.  Thanks. 

Thanks for your testing!

> I assume this is the correct fix even if the
> problem isn't completely understood?
> 

Hmm? Why do you say the problem isn't completely understood? I thought I
explained the problem in my changelog. Did I miss something?

Regards,
Srivatsa S. Bhat


  reply	other threads:[~2013-05-14  7:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-12  9:08 [v3.10-rc1] WARNING: at kernel/rcutree.c:502 Bjørn Mork
2013-05-12 11:39 ` Paul E. McKenney
2013-05-12 15:55   ` Bjørn Mork
2013-05-12 17:21     ` Paul E. McKenney
2013-05-12 18:19       ` Bjørn Mork
2013-05-12 20:58         ` Paul E. McKenney
2013-05-12 23:35         ` Bjørn Mork
2013-05-13 14:39           ` Bjørn Mork
2013-05-13 22:31             ` Srivatsa S. Bhat
2013-05-14  7:38               ` Bjørn Mork
2013-05-14  7:46                 ` Srivatsa S. Bhat [this message]
2013-05-14  7:51                   ` Srivatsa S. Bhat
2013-05-14  8:20                   ` Bjørn Mork
2013-05-14  8:21                     ` Srivatsa S. Bhat
2013-05-14 10:24               ` Paul E. McKenney
2013-05-14 15:50               ` [tip:core/urgent] rcu/idle: Wrap cpu-idle poll mode within rcu_idle_enter/exit tip-bot for Srivatsa S. Bhat

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=5191EBEF.4060409@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=bjorn@mork.no \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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).