Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754070AbbGBVIF (ORCPT ); Thu, 2 Jul 2015 17:08:05 -0400 Received: from mail.efficios.com ([78.47.125.74]:38386 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754348AbbGBVH4 (ORCPT ); Thu, 2 Jul 2015 17:07:56 -0400 Date: Thu, 2 Jul 2015 21:07:47 +0000 (UTC) From: Mathieu Desnoyers To: "Paul E. McKenney" Cc: Ingo Molnar , 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: <2087898187.25.1435871266994.JavaMail.zimbra@efficios.com> In-Reply-To: <20150702192331.GP3717@linux.vnet.ibm.com> References: <20150630234633.GA11450@cloud> <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> <1689655382.3088.1435862867358.JavaMail.zimbra@efficios.com> <20150702192331.GP3717@linux.vnet.ibm.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: bn5wx2q6QqqLRDyARlW90UVIZvvlgw== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2219 Lines: 55 ----- On Jul 2, 2015, at 3:23 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com wrote: > On Thu, Jul 02, 2015 at 06:47:47PM +0000, Mathieu Desnoyers wrote: >> ----- 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. > > My first thought is that a storm of expedited grace periods would be > most likely to show up in some error condition, and having them > splat might obscure the splats identifying the real problem. Or did > you have something else in mind here? Fair point! So I guess your checkpatch approach is more appropriate. 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/