From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753618AbdDLRHY (ORCPT ); Wed, 12 Apr 2017 13:07:24 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58071 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbdDLRHW (ORCPT ); Wed, 12 Apr 2017 13:07:22 -0400 Date: Wed, 12 Apr 2017 10:07:16 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: linux-kernel@vger.kernel.org Subject: Re: There is a Tasks RCU stall warning Reply-To: paulmck@linux.vnet.ibm.com References: <20170411174953.46adbf1e@gandalf.local.home> <20170411215656.GI1600@linux.vnet.ibm.com> <20170411181530.27dc21cc@gandalf.local.home> <20170411230154.GA3956@linux.vnet.ibm.com> <20170411230445.GA25951@linux.vnet.ibm.com> <20170411231138.GB25951@linux.vnet.ibm.com> <20170412144800.GA12365@linux.vnet.ibm.com> <20170412105937.43175471@gandalf.local.home> <20170412162754.GJ3956@linux.vnet.ibm.com> <20170412125722.5f9a974a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170412125722.5f9a974a@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17041217-0044-0000-0000-00000303082E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006924; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00846594; UDB=6.00417601; IPR=6.00625030; BA=6.00005286; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015022; XFM=3.00000013; UTC=2017-04-12 17:07:19 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041217-0045-0000-0000-000007310AD3 Message-Id: <20170412170716.GK3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-12_13:,, 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-1702020001 definitions=main-1704120140 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 12, 2017 at 12:57:22PM -0400, Steven Rostedt wrote: > On Wed, 12 Apr 2017 09:27:54 -0700 > "Paul E. McKenney" wrote: > > > On Wed, Apr 12, 2017 at 10:59:37AM -0400, Steven Rostedt wrote: > > > On Wed, 12 Apr 2017 07:48:00 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > > > > Like this? (Untested, but builds at least some of the time.) > > > > > > > > > > > > Not like that... :-/ Update on its way. > > > > > > > > > > Perhaps more like this. Started rcutorture on it, will see how it goes. > > > > > > I just love the above discussion with yourself ;-) > > > > Talking to oneself used to cause passersby to get really bent out of > > shape. But one big benefit of ubiquitous cellphones is that now > > people just assume that you are talking on a cellphone that they > > cannot see. ;-) > > > > > > Do you need this patch? If so, I should do some more work on it to > > > > eliminate the extra common-case branch on the scheduler fastpath. > > > > > > Do I still need this patch? Maybe. :-) > > > > > > I changed my benchmark test to call cond_resched_rcu_qs() instead and > > > that appears to fix the issue. But I'm not sure if there's any other > > > kthread out there that just calls cond_resched() or schedule(). > > > > > > Actually, I think it is still a good idea to have it. I believe that it > > > will still allow synchronize_rcu_tasks() to progress even if there's a > > > kthread task that is constantly being woken up, and never sleeps when > > > it calls schedule(), as it may always have the R state. > > > > OK, will optimize it a bit. When are you planning to get this in? > > > > Well, I added the use case for synchronize_rcu_tasks() in my current > for-next. I'll have to make sure I get the schedule_idle() in as well > as my update to the event benchmark thread as well. > > I don't think anything will truly break without it yet. But that's > assuming there's not another kernel thread somewhere that just spins > calling schedule. > > And this patch will still speed up those that do call > synchronize_rcu_tasks(). But that's an optimization and not really a > fix. The upcoming v4.12 merge window, then? Thanx, Paul