From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751479AbdIQBAX (ORCPT ); Sat, 16 Sep 2017 21:00:23 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49032 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751198AbdIQBAV (ORCPT ); Sat, 16 Sep 2017 21:00:21 -0400 Date: Sat, 16 Sep 2017 18:00:15 -0700 From: "Paul E. McKenney" To: Neeraj Upadhyay Cc: josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, sramana@codeaurora.org, prsood@codeaurora.org Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu Reply-To: paulmck@linux.vnet.ibm.com References: <8f33e48e-ac6d-2c88-e16f-20b698c06292@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8f33e48e-ac6d-2c88-e16f-20b698c06292@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17091701-0044-0000-0000-00000390D193 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007754; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000229; SDB=6.00918076; UDB=6.00461137; IPR=6.00698302; BA=6.00005592; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017183; XFM=3.00000015; UTC=2017-09-17 01:00:19 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17091701-0045-0000-0000-000007BFD366 Message-Id: <20170917010015.GW3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-17_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-1707230000 definitions=main-1709170012 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote: > Hi, > > We have one query regarding the behavior of RCU expedited grace period, > for scenario where resched_cpu() in sync_sched_exp_handler() fails to > acquire the rq lock and returns w/o setting the need_resched. In this > case, how do we ensure that the CPU notify rcu about the > end of sched grace period (schedule() -> __schedule() -> > rcu_note_context_switch(cpu) -> rcu_sched_qs()) , for cases where tick > is stopped on that CPU. Is it implied from the rq lock acquisition > failure, that the owner of the rq lock will enforce context switch? > For which scenarios in RCU paths (as the function is used only in RCU > code), we need trylock check in resched_cpu()? > > void resched_cpu(int cpu) > { > struct rq *rq = cpu_rq(cpu); > unsigned long flags; > > if (!raw_spin_trylock_irqsave(&rq->lock, flags)) > return; > resched_curr(rq); > raw_spin_unlock_irqrestore(&rq->lock, flags); > } > > > This issue was observed in below scenario, where one of the CPUs (CPU1) > started synchronize_sched_expedited and sent IPI to CPU5, which is in > the idle path but handled sync_sched_exp_handler() IPI before > rcu_idle_enter(). > As resched_cpu() failed to acquire the rq lock, need_resched was not set, > and CPU went to idle; resulting in expedited stall getting reported > by CPU1. > > Below is the scenario: > > • CPU1 is waiting for expedited wait to complete: > sync_rcu_exp_select_cpus > rdp->exp_dynticks_snap & 0x1 // returns 1 for CPU5 > IPI sent to CPU5 > > synchronize_sched_expedited_wait > ret = swait_event_timeout( > rsp->expedited_wq, > sync_rcu_preempt_exp_done(rnp_root), > jiffies_stall); > > expmask = 0x20 , and CPU 5 is in idle path (in cpuidle_enter()) > > > > • CPU5 handles IPI and fails to acquire rq lock. > > Handles IPI > sync_sched_exp_handler > resched_cpu > returns while failing to try lock acquire rq->lock > need_resched is not set > > • CPU5 calls rcu_idle_enter() and as need_resched is not set, goes to > idle (schedule() is not called). > > • CPU 1 reports RCU stall. Good catch and good detective work!!! I will be working on a fix this week, hopefully involving resched_cpu() getting a return value so that I can track who needs a later retry. Thanx, Paul