Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 21 Apr 2010 14:12:53 +0200 (CEST) | From | John Kacur <> | Subject | Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable. |
| |
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
| ![\](/images/icornerr.gif) |