Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753014AbbF3WA3 (ORCPT ); Tue, 30 Jun 2015 18:00:29 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:55737 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbbF3WAW (ORCPT ); Tue, 30 Jun 2015 18:00:22 -0400 Date: Tue, 30 Jun 2015 15:00:15 -0700 From: josh@joshtriplett.org To: "Paul E. McKenney" Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, tglx@linutronix.de, peterz@infradead.org, 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 RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones Message-ID: <20150630220014.GA10916@cloud> References: <20150630214805.GA7795@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150630214805.GA7795@linux.vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1442 Lines: 28 On Tue, Jun 30, 2015 at 02:48:05PM -0700, Paul E. McKenney wrote: > Hello! > > This series contains some highly experimental patches that allow normal > grace periods to take advantage of the work done by concurrent expedited > grace periods. This can reduce the overhead incurred by normal grace > periods by eliminating the need for force-quiescent-state scans that > would otherwise have happened after the expedited grace period completed. > It is not clear whether this is a useful tradeoff. Nevertheless, this > series contains the following patches: While it makes sense to avoid unnecessarily delaying a normal grace period if the expedited machinery has provided the necessary delay, I'm also *deeply* concerned that this will create a new class of nondeterministic performance issues. Something that uses RCU may perform badly due to grace period latency, but then suddenly start performing well because an unrelated task starts hammering expedited grace periods. This seems particularly likely during boot, for instance, where RCU grace periods can be a significant component of boot time (when you're trying to boot to userspace in small fractions of a second). - Josh Triplett -- 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/