Date: Mon, 28 Mar 2016 06:29:32 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>,
        Josh Triplett <josh@joshtriplett.org>, Ross Green <rgkernel@gmail.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        John Stultz <john.stultz@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>, dipankar@in.ibm.com,
        Andrew Morton <akpm@linux-foundation.org>,
        rostedt <rostedt@goodmis.org>, David Howells <dhowells@redhat.com>,
        Eric Dumazet <edumazet@google.com>,
        Darren Hart <dvhart@linux.intel.com>,
        =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec@gmail.com>,
        Oleg Nesterov <oleg@redhat.com>, pranith kumar <bobby.prani@gmail.com>,
        "Chatre, Reinette" <reinette.chatre@intel.com>
Subject: Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17
Message-ID: <20160328132932.GF4287@linux.vnet.ibm.com>
Reply-To: paulmck@linux.vnet.ibm.com
References: <20160223205522.GT3522@linux.vnet.ibm.com>
 <CANfgCY04Cnjoq1jQvQCd48Pt+_4Y9tcG6A7bCHHPWWWL6TFuEQ@mail.gmail.com>
 <CANfgCY3XCmArP9sJsdsQPGygyzWhzAXMS+jnge3_DCNYsONQyg@mail.gmail.com>
 <20160226005638.GV3522@linux.vnet.ibm.com>
 <20160318210011.GA571@cloud>
 <20160318235641.GH4287@linux.vnet.ibm.com>
 <20160321092230.75f23fa9@yairi>
 <20160327205439.GY6356@twins.programming.kicks-ass.net>
 <20160327210914.GD4287@linux.vnet.ibm.com>
 <20160328062851.GE6344@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160328062851.GE6344@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2527
Lines: 74

On Mon, Mar 28, 2016 at 08:28:51AM +0200, Peter Zijlstra wrote:
> On Sun, Mar 27, 2016 at 02:09:14PM -0700, Paul E. McKenney wrote:
> 
> > > Does that system have MONITOR/MWAIT errata?
> > 
> > On the off-chance that this question was also directed at me,
> 
> Hehe, it wasn't, however, since we're here..
> 
> > here is
> > what I am running on.  I am running in a qemu/KVM virtual machine, in
> > case that matters.
> 
> Have you actually tried on real proper hardware? Does it still reproduce
> there?

Ross has, but I have not, given that I have a shared system on the one
hand and a single-socket (four core, eight hardware thread) laptop on
the other that has even longer reproduction times.  The repeat-by is
as follows:

o	Build a kernel with the following Kconfigs:

	CONFIG_SMP=y
	CONFIG_NR_CPUS=16
	CONFIG_PREEMPT_NONE=n
	CONFIG_PREEMPT_VOLUNTARY=n
	CONFIG_PREEMPT=y
	# This should result in CONFIG_PREEMPT_RCU=y
	CONFIG_HZ_PERIODIC=y
	CONFIG_NO_HZ_IDLE=n
	CONFIG_NO_HZ_FULL=n
	CONFIG_RCU_TRACE=y
	CONFIG_HOTPLUG_CPU=y
	CONFIG_RCU_FANOUT=2
	CONFIG_RCU_FANOUT_LEAF=2
	CONFIG_RCU_NOCB_CPU=n
	CONFIG_DEBUG_LOCK_ALLOC=n
	CONFIG_RCU_BOOST=y
	CONFIG_RCU_KTHREAD_PRIO=2
	CONFIG_DEBUG_OBJECTS_RCU_HEAD=n
	CONFIG_RCU_EXPERT=y
	CONFIG_RCU_TORTURE_TEST=y
	CONFIG_PRINTK_TIME=y
	CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP=y
	CONFIG_RCU_TORTURE_TEST_SLOW_INIT=y
	CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT=y

	If desired, you can instead build with CONFIG_RCU_TORTURE_TEST=m
	and modprobe/insmod the module manually.

o	Find a two-socket x86 system or larger, with at least 16 CPUs.

o	Boot the kernel with the following kernel boot parameters:

	rcutorture.onoff_interval=1 rcutorture.onoff_holdoff=30

	The onoff_holdoff is only needed for CONFIG_RCU_TORTURE_TEST=y.
	When manually setting up the module, you get the holdoff for
	free, courtesy of human timescales.

In the absence of instrumentation, I get failures usually within a
couple of hours, though sometimes much longer.  With instrumentation,
the sky appears to be the limit.  :-/

Ross is running on bare metal with no CPU hotplug, so perhaps his setup
is of more immediate interest.  He is seeing the same symptoms that I am,
namely a task being repeatedly awakened without actually coming out of
TASK_INTERRUPTIBLE state, let alone running.  As you pointed out earlier,
he cannot be seeing the same bug that my crude patch suppresses, but
given that I still see a few failures with that crude patch, it is quite
possible that there is still a common bug.

							Thanx, Paul