From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753663Ab0DUMOE (ORCPT ); Wed, 21 Apr 2010 08:14:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24025 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752940Ab0DUMOA (ORCPT ); Wed, 21 Apr 2010 08:14:00 -0400 Date: Wed, 21 Apr 2010 14:12:53 +0200 (CEST) From: John Kacur X-X-Sender: jkacur@localhost.localdomain To: Peter Zijlstra cc: Andrew Morton , linux-kernel@vger.kernel.org, Ingo Molnar , linux-rt-users@vger.kernel.org, Thomas Gleixner , Clark Williams , "Luis Claudio R. Goncalves" , Gregory Haskins Subject: Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable. In-Reply-To: <1271849823.1776.87.camel@laptop> Message-ID: References: <20100420140941.d085007d.akpm@linux-foundation.org> <1271849823.1776.87.camel@laptop> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 21 Apr 2010, Peter Zijlstra wrote: > On Wed, 2010-04-21 at 13:12 +0200, John Kacur wrote: > > > > Certain configurations that have LOCKDEP turned on, run into the limit > > where the MAX_STACK_TRACE_ENTRIES are too small. Rather than simply > > turning of the locking correctness validator let the user configure this > > value to something reasonable for their system. > > I'm not sure its worth having a CONFIG_ value for this, that'll just be > yet another random value nobody knows what to do with. > > Do you actually have a machine that reproduces this? Can you see how > many classes, avg stacktraces per class and the avg entries per > stacktrace there are? This triggers every single time when I boot my T500 laptop with 2.6.33.2-rt13 with lots of debug options enabled. The problem is not specific to this kernel though. > > Also, is there's lots of classes, are there many with a similar name? > > That is, is it a valid depletion or is there something wonkey with those > setups? Here are the top 10 lines or so of /proc/lockdep_stats lock-classes: 1330 [max: 8191] direct dependencies: 12754 [max: 16384] indirect dependencies: 33245 all direct dependencies: 49074 dependency chains: 19641 [max: 32768] dependency chain hlocks: 73246 [max: 163840] in-hardirq chains: 25 in-softirq chains: 0 in-process chains: 19616 stack-trace entries: 262144 [max: 262144] I'm looking at more details in /proc/lockdep and friends to see if I can find any more details, or something that looks amiss. John