Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933438Ab0D3SM1 (ORCPT ); Fri, 30 Apr 2010 14:12:27 -0400 Received: from tomts10.bellnexxia.net ([209.226.175.54]:44298 "EHLO tomts10-srv.bellnexxia.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933787Ab0D3SMF (ORCPT ); Fri, 30 Apr 2010 14:12:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANu12ktGGNqG/2dsb2JhbACdIXK+doJmgiwE Date: Fri, 30 Apr 2010 14:12:01 -0400 From: Mathieu Desnoyers To: "Paul E. McKenney" Cc: Valdis.Kletnieks@vt.edu, Ingo Molnar , linux-kernel@vger.kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, josh@joshtriplett.org, dvhltc@us.ibm.com, niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, eric.dumazet@gmail.com Subject: Re: [PATCH tip/core/urgent] fix several lockdep splats, allow multiple splats Message-ID: <20100430181201.GB1704@Krystal> References: <20100421200150.GA3818@linux.vnet.ibm.com> <20100430100749.GC14202@elte.hu> <20100430153334.GA19672@Krystal> <10035.1272644205@localhost> <20100430180247.GA2482@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20100430180247.GA2482@linux.vnet.ibm.com> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 14:07:38 up 23 days, 4:01, 3 users, load average: 0.05, 0.08, 0.08 User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2335 Lines: 53 * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote: > On Fri, Apr 30, 2010 at 12:16:45PM -0400, Valdis.Kletnieks@vt.edu wrote: > > On Fri, 30 Apr 2010 11:33:34 EDT, Mathieu Desnoyers said: > > > > > I recommend creating a kernel command line parameter that would tweak > > > the number of messages printed by lockdep. The default would indeed by 1 > > > message, but people in a debugging marathon can specify a larger value > > > so they won't have to reboot between each individual lockdep error. > > > > Yeah, that would rock for development kernels - playing whack-a-mole with > > a half-dozen new lockdep whinges can easily stretch out for quite some time. > > The RCU-lockdep splats are a bit different in nature than the > deadlock-related splats that lockdep normally prints. The RCU-lockdep > splats are transient in nature, and it is easy to apply WARN_ON_ONCE(). > In contrast, if you permit multiple deadlock-related lockdep splats, > you tend to get lots of warnings about the same deadlock cycle. > > So how about an additional kernel configuration variable, default > disabled, perhaps named CONFIG_PROVE_RCU_MULTIPLE, that allows a > single boot to see multiple messages? Unlike the dyntick-idle > WARN_ON()s that generated multi-gigabyte console logs in a great > hurry, I haven't yet seen excessive quantities of RCU-lockdep splats, > so I don't see the need for an integer limit. > > Thoughts? Ideally we don't want to flood the console with thousands of instances of the same RCU-lockdep splat (think of a missing read lock on a common code path). Therefore I think keeping an integer limit is relevant here. I agree that this integer limit could be selected by a CONFIG_ option rather than by a kernel parameter, as it will typically only be used on development kernels with "kernel hacking" enabled anyway. There is not much point in bloating the kernel code with an extra debug-only kernel parameter parsing. Thanks, Mathieu > > Thanx, Paul -- Mathieu Desnoyers Operating System Efficiency R&D Consultant 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/