[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171018053124.GB32368@X58A-UD3R>
Date: Wed, 18 Oct 2017 14:31:24 +0900
From: Byungchul Park <byungchul.park@....com>
To: Ingo Molnar <mingo@...nel.org>
Cc: johan@...nel.org, arnd@...db.de, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
peterz@...radead.org, hpa@...or.com, tony@...mide.com,
linux-tip-commits@...r.kernel.org, kernel-team@....com
Subject: Re: [tip:locking/urgent] locking/lockdep: Disable cross-release
features for now
On Tue, Oct 17, 2017 at 09:12:02AM +0200, Ingo Molnar 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.
OK. I will fx the performance problem by making the unwinding optional.
Powered by blists - more mailing lists