Re: [tip:core/rcu] Revert "rcu: Decrease memory-barrier usage based on semi-formal proof"

From: Yinghai Lu <yinghai@kernel.org>
To: paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [tip:core/rcu] Revert "rcu: Decrease memory-barrier usage based on semi-formal proof"
Date: Thu, 26 May 2011 08:08:26 -0700	[thread overview]
Message-ID: <BANLkTinC2q6Fjf7=2GZoJ=+c+fzpdwAvuQ@mail.gmail.com> (raw)
In-Reply-To: <20110526013029.GA28103@linux.vnet.ibm.com>

On Wed, May 25, 2011 at 6:30 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Wed, May 25, 2011 at 06:13:10PM -0700, Paul E. McKenney wrote:
>> On Wed, May 25, 2011 at 03:49:25PM -0700, Yinghai Lu wrote:
>> > On 05/25/2011 03:34 PM, Paul E. McKenney wrote:
>> > > On Wed, May 25, 2011 at 03:15:50PM -0700, Yinghai Lu wrote:
>> > >>> There is a new branch yinghai.2011.05.24a on:
>> > >>>
>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
>> > >>>
>> > >>> Or will be as soon as kernel.org updates its mirrors.
>> > >>>
>> > >>> I am not sure I could call this "clean", but it does revert that commit
>> > >>> and 11 of the subsequent commits that depend on it.  It does build,
>> > >>> and I will test it once my currently running tests complete.
>> > >>
>> > >> yes, with those revert, there is no delay in 10 times booting.
>> > >
>> > > Unfortunately, there are rcutorture test failures with the revert...
>> >
>> > confused.
>>
>> Given what I had to do to generate the revert, not exactly a surprise,
>> I am afraid.  Just means that the resulting RCU sometimes fails to
>> wait for all pre-existing readers, and rcutorture catches it.
>>
>> > what is the next?
>>
>> 1.    I send you a patch that I hope will fix the softlockup
>>       you saw.  I am testing this.
>>
>> 2.    I am working on more detailed instrumentation, and will
>>       send a patch on that.
>>
>> 3.    If time allows, break down the operations RCU is doing
>>       and test them in isolation.
>>
>> Other thoughts?
>
> And here is patch #1.  Could you please try applying this on top of
> Peter Zijlstra's patch to see if it gets rid of the softlockups you saw?
>
>                                                        Thanx, Paul
>
> ------------------------------------------------------------------------
>
> rcu: Start RCU kthreads in TASK_INTERRUPTIBLE state
>
> Upon creation, kthreads are in TASK_UNINTERRUPTIBLE state, which can
> result in softlockup warnings.  Because some of RCU's kthreads can
> legitimately be idle indefinitely, start them in TASK_INTERRUPTIBLE
> state in order to avoid those warnings.
>

Yes, it fixes the lock up warning.

Thanks

Yinghai