From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933595AbcKGTE3 (ORCPT ); Mon, 7 Nov 2016 14:04:29 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44993 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932916AbcKGTE1 (ORCPT ); Mon, 7 Nov 2016 14:04:27 -0500 Date: Mon, 7 Nov 2016 11:04:12 -0800 From: "Paul E. McKenney" To: Josh Triplett Cc: Sebastian Andrzej Siewior , Steven Rostedt , "Michael S. Tsirkin" , Julia Cartwright , Luiz Capitulino , linux-rt-users@vger.kernel.org, Mathieu Desnoyers , Lai Jiangshan , linux-kernel@vger.kernel.org Subject: Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default Reply-To: paulmck@linux.vnet.ibm.com References: <20161031181543.GN3716@linux.vnet.ibm.com> <20161102163002.igni3zdnid535nou@linutronix.de> <20161103162228.GG3716@linux.vnet.ibm.com> <20161103163326.jkjbncoz7a5oriy5@linutronix.de> <20161103165931.GJ3716@linux.vnet.ibm.com> <20161107121939.7346923f@gandalf.local.home> <20161107173029.caktxw4piluk5atu@linutronix.de> <20161107173546.t7aokzncidauio43@x> <20161107180513.GQ24166@linux.vnet.ibm.com> <20161107180831.nrwg2k7h5cghntwu@x> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161107180831.nrwg2k7h5cghntwu@x> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16110719-0020-0000-0000-00000A310240 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006040; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00777817; UDB=6.00374526; IPR=6.00555134; BA=6.00004861; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013239; XFM=3.00000011; UTC=2016-11-07 19:04:16 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16110719-0021-0000-0000-00005711D28A Message-Id: <20161107190412.GT24166@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-07_08:,, 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-1609300000 definitions=main-1611070349 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 07, 2016 at 10:08:32AM -0800, Josh Triplett wrote: > On Mon, Nov 07, 2016 at 10:05:13AM -0800, Paul E. McKenney wrote: > > On Mon, Nov 07, 2016 at 09:35:46AM -0800, Josh Triplett wrote: > > > On Mon, Nov 07, 2016 at 06:30:30PM +0100, Sebastian Andrzej Siewior wrote: > > > > On 2016-11-07 12:19:39 [-0500], Steven Rostedt wrote: > > > > > I agree, but if this creates a boot time regression in large machines, > > > > > it may not be warranted. > > > > > > > > > > I know Linus usually doesn't like options with default y, but this may > > > > > be one of those exceptions. Perhaps we should make it on by default and > > > > > say in the config "if you have a machine with 100s or 1000s of CPUs, > > > > > you may want to disable this". > > > > > > > > The default could change if we know where the limit is. I have access to > > > > a box with approx 140 CPUs so I could check there if it is already bad. > > > > But everything above that / in the 1000 range is a different story. > > > > > > Right; if we can characterize what machines it benefits and what > > > machines it hurts, we can automatically detect and run the appropriate > > > case with no configuration option needed. > > > > I very much like this approach! Anyone have access to large systems on > > which this experiment could be carried out? In the absence of new data, > > I would just set the cutoff at 256 CPUs, as I have done in the past. > > One potential issue here: the point where RCU_EXPEDITE_BOOT pessimizes > likely depends on interconnect as much as CPUs. I'd guess that you may > want to set the cutoff based on number of NUMA nodes, rather than number > of CPUs. Longer term, the solution would be a function that defined the cutoff point. If an architecture didn't define the function, they get the default cutoff of 256. If they do define the function, they get whatever they coded. Thanx, Paul