Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754237AbbGBSr4 (ORCPT ); Thu, 2 Jul 2015 14:47:56 -0400 Received: from mail.efficios.com ([78.47.125.74]:37466 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754048AbbGBSrt (ORCPT ); Thu, 2 Jul 2015 14:47:49 -0400 Date: Thu, 2 Jul 2015 18:47:47 +0000 (UTC) From: Mathieu Desnoyers To: Ingo Molnar Cc: "Paul E. McKenney" , Peter Zijlstra , josh@joshtriplett.org, linux-kernel@vger.kernel.org, Lai Jiangshan , dipankar@in.ibm.com, Andrew Morton , tglx@linutronix.de, rostedt , dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby prani Message-ID: <1689655382.3088.1435862867358.JavaMail.zimbra@efficios.com> In-Reply-To: <20150702183557.GA15331@gmail.com> References: <20150630234633.GA11450@cloud> <20150701141710.GG25159@twins.programming.kicks-ass.net> <20150701161705.GK3717@linux.vnet.ibm.com> <20150701170242.GL3644@twins.programming.kicks-ass.net> <20150701200936.GP3717@linux.vnet.ibm.com> <20150702074719.GA27230@gmail.com> <20150702135834.GF3717@linux.vnet.ibm.com> <20150702183557.GA15331@gmail.com> Subject: Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging normal ones MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1153) Thread-Topic: Expedited grace periods encouraging normal ones Thread-Index: I2+tAzxUG9w+O16Tif2mrHSc8/ZYQQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1650 Lines: 45 ----- On Jul 2, 2015, at 2:35 PM, Ingo Molnar mingo@kernel.org wrote: > * Paul E. McKenney wrote: > >> > And it's not like it's that hard to stem the flow of algorithmic sloppiness at >> > the source, right? >> >> OK, first let me make sure that I understand what you are asking for: >> >> 1. Completely eliminate synchronize_rcu_expedited() and >> synchronize_sched_expedited(), replacing all uses with their >> unexpedited counterparts. (Note that synchronize_srcu_expedited() >> does not wake up CPUs, courtesy of its read-side memory barriers.) >> The fast-boot guys are probably going to complain, along with >> the networking guys. >> >> 2. Keep synchronize_rcu_expedited() and synchronize_sched_expedited(), >> but push back hard on any new uses and question any existing uses. >> >> 3. Revert 74b51ee152b6 ("ACPI / osl: speedup grace period in >> acpi_os_map_cleanup"). >> >> 4. Something else? > > I'd love to have 1) but 2) would be a realistic second best option? ;-) Perhaps triggering a printk warning if use of synchronize_{rcu,sched}_expedited() go beyond of certain rate might be another option ? If we detect that a caller calls it too often, we could emit a printk warning with a stack trace. This should ensure everyone is very careful about where they use it. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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/