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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
