Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751736AbbBUQJK (ORCPT ); Sat, 21 Feb 2015 11:09:10 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:37045 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751427AbbBUQJG (ORCPT ); Sat, 21 Feb 2015 11:09:06 -0500 Date: Sat, 21 Feb 2015 17:08:52 +0100 From: Peter Zijlstra To: Arjan van de Ven Cc: paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH tip/core/rcu 0/4] Programmatic nestable expedited grace periods Message-ID: <20150221160852.GI23367@worktop.ger.corp.intel.com> References: <20150220050850.GA32639@linux.vnet.ibm.com> <20150220091107.GN21418@twins.programming.kicks-ass.net> <20150220163737.GL5745@linux.vnet.ibm.com> <20150220165409.GU5029@twins.programming.kicks-ass.net> <20150220171442.GM5745@linux.vnet.ibm.com> <54E76FB7.4060005@linux.intel.com> <20150220174359.GW5029@twins.programming.kicks-ass.net> <54E772C3.30508@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E772C3.30508@linux.intel.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 32 On Fri, Feb 20, 2015 at 09:45:39AM -0800, Arjan van de Ven wrote: > On 2/20/2015 9:43 AM, Peter Zijlstra wrote: > >On Fri, Feb 20, 2015 at 09:32:39AM -0800, Arjan van de Ven wrote: > >>there's a few others as well that I'm chasing down... > >>.. but the flip side, prior to running ring 3 code, why NOT do fast expedites? > > > >So my objections are twofold: > > > > - I object to fast expedites in principle; they spray IPIs across the > > system, so ideally we'd not have them at all, therefore also not at > > boot. > > > > Because as soon as the option exists, people will use it for other > > things too. > > the option exists today in sysfs and kernel parameter... Yeah, Paul and me have been having this argument for a while now ;-) > >And esp. in bootup code you can special case a lot of stuff; there's > >limited concurrency esp. because userspace it not there yet. So we might > >not actually need those sync calls. > > yeah I am going down that angle as well absolutely. > but there are cases that may well be legit (or are 5 function calls deep into common code) Good ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/