Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.

[John Kacur <jkacur@redhat.com>]

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