From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3xHrYY0bPyzDrCv for ; Thu, 27 Jul 2017 09:15:12 +1000 (AEST) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6QNDhnD098736 for ; Wed, 26 Jul 2017 19:15:10 -0400 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0a-001b2d01.pphosted.com with ESMTP id 2by1jxf8cn-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Jul 2017 19:15:09 -0400 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 26 Jul 2017 19:15:09 -0400 Date: Wed, 26 Jul 2017 16:15:05 -0700 From: "Paul E. McKenney" To: David Miller Cc: Jonathan.Cameron@huawei.com, dzickus@redhat.com, sfr@canb.auug.org.au, linuxarm@huawei.com, npiggin@gmail.com, abdhalee@linux.vnet.ibm.com, sparclinux@vger.kernel.org, akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this? Reply-To: paulmck@linux.vnet.ibm.com References: <20170726.095432.169004918437663011.davem@davemloft.net> <20170726175013.GT3730@linux.vnet.ibm.com> <20170726223658.GA27617@linux.vnet.ibm.com> <20170726.154540.150558937277891719.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20170726.154540.150558937277891719.davem@davemloft.net> Message-Id: <20170726231505.GG3730@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Jul 26, 2017 at 03:45:40PM -0700, David Miller wrote: > From: "Paul E. McKenney" > Date: Wed, 26 Jul 2017 15:36:58 -0700 > > > And without CONFIG_SOFTLOCKUP_DETECTOR, I see five runs of 24 with RCU > > CPU stall warnings. So it seems likely that CONFIG_SOFTLOCKUP_DETECTOR > > really is having an effect. > > Thanks for all of the info Paul, I'll digest this and scan over the > code myself. > > Just out of curiousity, what x86 idle method is your machine using? > The mwait one or the one which simply uses 'halt'? The mwait variant > might mask this bug, and halt would be a lot closer to how sparc64 and > Jonathan's system operates. My kernel builds with CONFIG_INTEL_IDLE=n, which I believe means that I am not using the mwait one. Here is a grep for IDLE in my .config: CONFIG_NO_HZ_IDLE=y CONFIG_GENERIC_SMP_IDLE_THREAD=y # CONFIG_IDLE_PAGE_TRACKING is not set CONFIG_ACPI_PROCESSOR_IDLE=y CONFIG_CPU_IDLE=y # CONFIG_CPU_IDLE_GOV_LADDER is not set CONFIG_CPU_IDLE_GOV_MENU=y # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set # CONFIG_INTEL_IDLE is not set > On sparc64 the cpu yield we do in the idle loop sleeps the cpu. It's > local TICK register keeps advancing, and the local timer therefore > will still trigger. Also, any externally generated interrupts > (including cross calls) will wake up the cpu as well. > > The tick-sched code is really tricky wrt. NO_HZ even in the NO_HZ_IDLE > case. One of my running theories is that we miss scheduling a tick > due to a race. That would be consistent with the behavior we see > in the RCU dumps, I think. But wouldn't you have to miss a -lot- of ticks to get an RCU CPU stall warning? By default, your grace period needs to extend for more than 21 seconds (more than one-third of a -minute-) to get one. Or do you mean that the ticks get shut off now and forever, as opposed to just losing one of them? > Anyways, just a theory, and that's why I keep mentioning that commit > about the revert of the revert (specifically > 411fe24e6b7c283c3a1911450cdba6dd3aaea56e). > > :-) I am running an overnight test in preparation for attempting to push some fixes for regressions into 4.12, but will try reverting this and enabling CONFIG_HZ_PERIODIC tomorrow. Jonathan, might the commit that Dave points out above be what reduces the probability of occurrence as you test older releases? Thanx, Paul