lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable.
From
Date
On Wed, 2010-04-21 at 14:12 +0200, John Kacur wrote:
>
> 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.
>

Working from ancient memory here:

I think that this is seen more on the distro side - had the same problem
with SLERT.

And yes, it did show up more with additional debug options -- when
structs with #ifdef DEBUG_XXX are populated.

IIRC there is another caveat, if MAX_STACK_TRACE_ENTRIES is too large,
you run out of memory uncompressing the Kernel (on 32 bit only?) and it
hangs.

We put patches in place to manually increase to something workable, but
I would ACK this change, allowing tinkering.

Regards,

Sven



\
 
 \ /
  Last update: 2010-04-21 16:55    [W:0.029 / U:0.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site