From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932088AbdGYCoZ (ORCPT ); Mon, 24 Jul 2017 22:44:25 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36332 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756412AbdGYCoQ (ORCPT ); Mon, 24 Jul 2017 22:44:16 -0400 Date: Mon, 24 Jul 2017 19:44:11 -0700 From: "Paul E. McKenney" To: David Miller Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org Subject: Re: RCU stall warnings... Reply-To: paulmck@linux.vnet.ibm.com References: <20170724.153248.1457902120749226419.davem@davemloft.net> <20170724232033.GI3730@linux.vnet.ibm.com> <20170724.163458.1860624258080140141.davem@davemloft.net> <20170724234927.GK3730@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170724234927.GK3730@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17072502-0040-0000-0000-000003853C63 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007420; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00892472; UDB=6.00446081; IPR=6.00672636; BA=6.00005489; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016361; XFM=3.00000015; UTC=2017-07-25 02:44:14 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072502-0041-0000-0000-0000077959BD Message-Id: <20170725024411.GA27413@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-25_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250043 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 24, 2017 at 04:49:27PM -0700, Paul E. McKenney wrote: > On Mon, Jul 24, 2017 at 04:34:58PM -0700, David Miller wrote: > > From: "Paul E. McKenney" > > Date: Mon, 24 Jul 2017 16:20:33 -0700 [ . . . ] > > That would take a while as it's hard to forcibly set this thing off. > > And my similar error can take awhile as well. But maybe I should try > forcing nr_cpus=43 and maxcpus=8 on older versions to see what happens. > > A bisection would of course be quite helpful, depending of course on > the value of "a while". ;-) And if "a while" is too long, one alternative is to enable event tracing for timers, as in why didn't they wake the grace-period kthread? For example, it is possible that that kthread set its status (which was printed out in the "rcu_sched kthread starved" message) but for whatever reason didn't make it to the swait_event_idle_timeout() immediately afterwards; rsp->gp_state = RCU_GP_WAIT_FQS; ret = swait_event_idle_timeout(rsp->gp_wq, rcu_gp_fqs_check_wake(rsp, &gf), j); Or that the timer-based wakeup didn't happen for whatever reason. Or... Thanx, Paul > > ==================== > > commit f92c734f02cbf10e40569facff82059ae9b61920 > > Author: Paul E. McKenney > > Date: Mon Apr 10 15:40:35 2017 -0700 > > > > rcu: Prevent rcu_barrier() from starting needless grace periods > > > > Currently rcu_barrier() uses call_rcu() to enqueue new callbacks > > on each CPU with a non-empty callback list. This works, but means > > that rcu_barrier() forces grace periods that are not otherwise needed. > > The key point is that rcu_barrier() never needs to wait for a grace > > period, but instead only for all pre-existing callbacks to be invoked. > > This means that rcu_barrier()'s new callbacks should be placed in > > the callback-list segment containing the last pre-existing callback. > > > > This commit makes this change using the new rcu_segcblist_entrain() > > function. > > > > Signed-off-by: Paul E. McKenney > >