Re: [tip:locking/urgent] locking/lockdep: Disable cross-release features for now

[Ingo Molnar]

* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

> On Tue, 17 Oct 2017, Ingo Molnar wrote:
> > * Byungchul Park <byungchul.park@xxxxxxx> wrote:
> > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > > index 2689b7c..e270584 100644
> > > > --- a/lib/Kconfig.debug
> > > > +++ b/lib/Kconfig.debug
> > > > @@ -1092,8 +1092,8 @@ config PROVE_LOCKING
> > > >  	select DEBUG_MUTEXES
> > > >  	select DEBUG_RT_MUTEXES if RT_MUTEXES
> > > >  	select DEBUG_LOCK_ALLOC
> > > > -	select LOCKDEP_CROSSRELEASE
> > > > -	select LOCKDEP_COMPLETIONS
> > > > +	select LOCKDEP_CROSSRELEASE if BROKEN
> > > > +	select LOCKDEP_COMPLETIONS if BROKEN
> > > 
> > > I agree with disabling crossrelease as default, becasue of regression,
> > > as I originally did.
> > > 
> > > However, it's expected to spend more time once it's enabled. Is the
> > > following acceptable?
> > 
> > No, please fix performance.
> 
> You know very well that with the cross release stuff we have to take the
> performance hit of stack unwinding because we have no idea whether there
> will show up a new lock relation later or not. And there is not much you
> can do in that respect.
> 
> OTOH, the cross release feature unearthed real deadlocks already so it is a
> valuable debug feature and having an explicit config switch which defaults
> to N is well worth it.

I disagree, because even if that's correct, the choices are not binary. The 
performance regression was a slowdown of around 7x: lockdep boot overhead on that 
particula system went from +3 seconds to +21 seconds...

As a response to the performance regression I haven't seen _any_ attempt to 
measure, profile and generally quantify the performance impact, which would at 
least make it more believable that the overhead cannot be reduced. That really 
makes me worry about the code on a higher level than just whether it can be 
enabled by default or not.

Caring about the performance of debug features very much matters, _especially_ 
when they are expensive.

Thanks,

	Ingo