All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: paulmck@linux.vnet.ibm.com
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>, MarkRutland <mark.rutland@arm.com>
Subject: Re: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 04 Feb 2015 17:43:44 +0100	[thread overview]
Message-ID: <1423068224.24415.15.camel@AMDC1943> (raw)
In-Reply-To: <20150204162814.GG5370@linux.vnet.ibm.com>

On śro, 2015-02-04 at 08:28 -0800, Paul E. McKenney wrote:
> On Wed, Feb 04, 2015 at 05:10:56PM +0100, Krzysztof Kozlowski wrote:
> > On śro, 2015-02-04 at 07:56 -0800, Paul E. McKenney wrote:
> > > On Wed, Feb 04, 2015 at 04:22:28PM +0100, Krzysztof Kozlowski wrote:
> > > > 
> > > > Actually the timeout versions but I think that doesn't matter.
> > > > The wait_on_bit will busy-loop with testing for the bit. Inside the loop
> > > > it calls the 'action' which in my case will be bit_wait_io_timeout().
> > > > This calls schedule_timeout().
> > > 
> > > Ah, good point.
> > > 
> > > > See proof of concept in attachment. One observed issue: hot unplug from
> > > > commandline takes a lot more time. About 7 seconds instead of ~0.5.
> > > > Probably I did something wrong.
> > > 
> > > Well, you do set the timeout to five seconds, and so if the condition
> > > does not get set before the surviving CPU finds its way to the
> > > out_of_line_wait_on_bit_timeout(), you are guaranteed to wait for at
> > > least five seconds.
> > >
> > > One alternative approach would be to have a loop around a series of
> > > shorter waits.  Other thoughts?
> > 
> > Right! That was the issue. It seems it works. I'll think also on
> > self-adapting interval as you said below. I'll test it more and send a
> > patch.
> 
> Sounds good!
> 
> Are you doing ARM, ARM64, or both?  I of course vote for both.  ;-)

I'll do both but first I need to find who has ARM64 board in my team.

Best regards,
Krzysztof




WARNING: multiple messages have this Message-ID (diff)
From: k.kozlowski@samsung.com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 04 Feb 2015 17:43:44 +0100	[thread overview]
Message-ID: <1423068224.24415.15.camel@AMDC1943> (raw)
In-Reply-To: <20150204162814.GG5370@linux.vnet.ibm.com>

On ?ro, 2015-02-04 at 08:28 -0800, Paul E. McKenney wrote:
> On Wed, Feb 04, 2015 at 05:10:56PM +0100, Krzysztof Kozlowski wrote:
> > On ?ro, 2015-02-04 at 07:56 -0800, Paul E. McKenney wrote:
> > > On Wed, Feb 04, 2015 at 04:22:28PM +0100, Krzysztof Kozlowski wrote:
> > > > 
> > > > Actually the timeout versions but I think that doesn't matter.
> > > > The wait_on_bit will busy-loop with testing for the bit. Inside the loop
> > > > it calls the 'action' which in my case will be bit_wait_io_timeout().
> > > > This calls schedule_timeout().
> > > 
> > > Ah, good point.
> > > 
> > > > See proof of concept in attachment. One observed issue: hot unplug from
> > > > commandline takes a lot more time. About 7 seconds instead of ~0.5.
> > > > Probably I did something wrong.
> > > 
> > > Well, you do set the timeout to five seconds, and so if the condition
> > > does not get set before the surviving CPU finds its way to the
> > > out_of_line_wait_on_bit_timeout(), you are guaranteed to wait for at
> > > least five seconds.
> > >
> > > One alternative approach would be to have a loop around a series of
> > > shorter waits.  Other thoughts?
> > 
> > Right! That was the issue. It seems it works. I'll think also on
> > self-adapting interval as you said below. I'll test it more and send a
> > patch.
> 
> Sounds good!
> 
> Are you doing ARM, ARM64, or both?  I of course vote for both.  ;-)

I'll do both but first I need to find who has ARM64 board in my team.

Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: lkp@lists.01.org
Subject: Re: [rcu] [ INFO: suspicious RCU usage. ]
Date: Wed, 04 Feb 2015 17:43:44 +0100	[thread overview]
Message-ID: <1423068224.24415.15.camel@AMDC1943> (raw)
In-Reply-To: <20150204162814.GG5370@linux.vnet.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On śro, 2015-02-04 at 08:28 -0800, Paul E. McKenney wrote:
> On Wed, Feb 04, 2015 at 05:10:56PM +0100, Krzysztof Kozlowski wrote:
> > On śro, 2015-02-04 at 07:56 -0800, Paul E. McKenney wrote:
> > > On Wed, Feb 04, 2015 at 04:22:28PM +0100, Krzysztof Kozlowski wrote:
> > > > 
> > > > Actually the timeout versions but I think that doesn't matter.
> > > > The wait_on_bit will busy-loop with testing for the bit. Inside the loop
> > > > it calls the 'action' which in my case will be bit_wait_io_timeout().
> > > > This calls schedule_timeout().
> > > 
> > > Ah, good point.
> > > 
> > > > See proof of concept in attachment. One observed issue: hot unplug from
> > > > commandline takes a lot more time. About 7 seconds instead of ~0.5.
> > > > Probably I did something wrong.
> > > 
> > > Well, you do set the timeout to five seconds, and so if the condition
> > > does not get set before the surviving CPU finds its way to the
> > > out_of_line_wait_on_bit_timeout(), you are guaranteed to wait for at
> > > least five seconds.
> > >
> > > One alternative approach would be to have a loop around a series of
> > > shorter waits.  Other thoughts?
> > 
> > Right! That was the issue. It seems it works. I'll think also on
> > self-adapting interval as you said below. I'll test it more and send a
> > patch.
> 
> Sounds good!
> 
> Are you doing ARM, ARM64, or both?  I of course vote for both.  ;-)

I'll do both but first I need to find who has ARM64 board in my team.

Best regards,
Krzysztof




  reply	other threads:[~2015-02-04 16:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-01  2:59 [rcu] [ INFO: suspicious RCU usage. ] Fengguang Wu
2015-02-01  2:59 ` Fengguang Wu
2015-02-03 10:01 ` Krzysztof Kozlowski
2015-02-03 10:01   ` Krzysztof Kozlowski
2015-02-03 16:27   ` Paul E. McKenney
2015-02-03 16:27     ` Paul E. McKenney
2015-02-04 11:39     ` Krzysztof Kozlowski
2015-02-04 11:39       ` Krzysztof Kozlowski
2015-02-04 11:39       ` Krzysztof Kozlowski
2015-02-04 13:00       ` Russell King - ARM Linux
2015-02-04 13:00         ` Russell King - ARM Linux
2015-02-04 13:00         ` Russell King - ARM Linux
2015-02-04 13:14         ` Paul E. McKenney
2015-02-04 13:14           ` Paul E. McKenney
2015-02-04 13:14           ` Paul E. McKenney
2015-02-04 14:16           ` Krzysztof Kozlowski
2015-02-04 14:16             ` Krzysztof Kozlowski
2015-02-04 14:16             ` Krzysztof Kozlowski
2015-02-04 15:10             ` Paul E. McKenney
2015-02-04 15:10               ` Paul E. McKenney
2015-02-04 15:10               ` Paul E. McKenney
2015-02-04 15:16               ` Russell King - ARM Linux
2015-02-04 15:16                 ` Russell King - ARM Linux
2015-02-04 15:16                 ` Russell King - ARM Linux
2015-02-04 15:46                 ` Paul E. McKenney
2015-02-04 15:46                   ` Paul E. McKenney
2015-02-04 15:46                   ` Paul E. McKenney
2015-02-04 15:22               ` Krzysztof Kozlowski
2015-02-04 15:22                 ` Krzysztof Kozlowski
2015-02-04 15:22                 ` Krzysztof Kozlowski
2015-02-04 15:56                 ` Paul E. McKenney
2015-02-04 15:56                   ` Paul E. McKenney
2015-02-04 15:56                   ` Paul E. McKenney
2015-02-04 16:10                   ` Krzysztof Kozlowski
2015-02-04 16:10                     ` Krzysztof Kozlowski
2015-02-04 16:10                     ` Krzysztof Kozlowski
2015-02-04 16:28                     ` Paul E. McKenney
2015-02-04 16:28                       ` Paul E. McKenney
2015-02-04 16:28                       ` Paul E. McKenney
2015-02-04 16:43                       ` Krzysztof Kozlowski [this message]
2015-02-04 16:43                         ` Krzysztof Kozlowski
2015-02-04 16:43                         ` Krzysztof Kozlowski
2015-02-04 13:13       ` Paul E. McKenney
2015-02-04 13:13         ` Paul E. McKenney
2015-02-04 13:13         ` Paul E. McKenney

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=1423068224.24415.15.camel@AMDC1943 \
    --to=k.kozlowski@samsung.com \
    --cc=arnd@arndb.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lkp@01.org \
    --cc=mark.rutland@arm.com \
    --cc=paulmck@linux.vnet.ibm.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.