From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752798AbdBMTwz (ORCPT ); Mon, 13 Feb 2017 14:52:55 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34290 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752490AbdBMTwx (ORCPT ); Mon, 13 Feb 2017 14:52:53 -0500 Date: Mon, 13 Feb 2017 11:52:49 -0800 From: "Paul E. McKenney" To: Andy Lutomirski Cc: Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Andrew Lutomirski , Thomas Gleixner , Frederic Weisbecker , Chris Metcalf , Ingo Molnar Subject: Re: [PATCH RFC v2 tip/core/rcu] Maintain special bits at bottom of ->dynticks counter Reply-To: paulmck@linux.vnet.ibm.com References: <20170209235103.GA1368@linux.vnet.ibm.com> <20170213122115.GO6515@twins.programming.kicks-ass.net> <20170213170104.GC30506@linux.vnet.ibm.com> <20170213175750.GJ6500@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17021319-0012-0000-0000-000013A4B4A7 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006610; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000203; SDB=6.00821466; UDB=6.00401766; IPR=6.00598919; BA=6.00005133; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014269; XFM=3.00000011; UTC=2017-02-13 19:52:49 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17021319-0013-0000-0000-00004B622F95 Message-Id: <20170213195249.GN30506@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-13_10:,, 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-1612050000 definitions=main-1702130190 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 13, 2017 at 11:08:55AM -0800, Andy Lutomirski wrote: > On Mon, Feb 13, 2017 at 9:57 AM, Peter Zijlstra wrote: > > On Mon, Feb 13, 2017 at 09:01:04AM -0800, Paul E. McKenney wrote: > >> > I think I've asked this before, but why does this live in the guts of > >> > RCU? > >> > > >> > Should we lift this state tracking stuff out and make RCU and > >> > NOHZ(_FULL) users of it, or doesn't that make sense (reason)? > >> > >> The dyntick-idle stuff is pretty specific to RCU. And what precisely > >> would be helped by moving it? > > > > Maybe untangle the inter-dependencies somewhat. It just seems a wee bit > > odd to have arch TLB invalidate depend on RCU implementation details > > like this. > > This came out of a courtyard discussion at KS/LPC. The idea is that > this optimzation requires an atomic op that could be shared with RCU > and that we probably care a lot more about this optimization on > kernels with context tracking enabled, so putting it in RCU has nice > performance properties. Other than that, it doesn't make a huge > amount of sense. > > Amusingly, Darwin appears to do something similar without an atomic > op, and I have no idea why that's safe. Given that they run on ARM, I have no idea either. Maybe they don't need to be quite as bulletproof on idle-duration detection? Rumor has it that their variant of RCU uses program-counter ranges, so they wouldn't have the RCU tie-in -- just checks of program-counter ranges and interesting dependencies on the compiler. Thanx, Paul