All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Johan Hovold <johan@kernel.org>
Cc: Byungchul Park <byungchul.park@lge.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	linux-mm@kvack.org, kernel-team@lge.com,
	Tony Lindgren <tony@atomide.com>, Arnd Bergmann <arnd@arndb.de>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Dramatic lockdep slowdown in 4.14
Date: Sat, 14 Oct 2017 09:26:59 +0200	[thread overview]
Message-ID: <20171014072659.f2yr6mhm5ha3eou7@gmail.com> (raw)
In-Reply-To: <20171013090333.GA17356@localhost>


* Johan Hovold <johan@kernel.org> wrote:

> Hi,
> 
> I had noticed that the BeagleBone Black boot time appeared to have
> increased significantly with 4.14 and yesterday I finally had time to
> investigate it.
> 
> Boot time (from "Linux version" to login prompt) had in fact doubled
> since 4.13 where it took 17 seconds (with my current config) compared to
> the 35 seconds I now see with 4.14-rc4.
> 
> I quick bisect pointed to lockdep and specifically the following commit:
> 
> 	28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition
> 	               of a crosslock")
> 
> which I've verified is the commit which doubled the boot time (compared
> to 28a903f63ec0^) (added by lockdep crossrelease series [1]).
> 
> I also verified that simply disabling CONFIG_PROVE_LOCKING on 4.14-rc4
> brought boot time down to about 14 seconds.
> 
> Now since it's lockdep I guess this can't really be considered a
> regression if these changes did improve lockdep correctness, but still,
> this dramatic slow down essentially forces me to disable PROVE_LOCKING
> by default on this system.
> 
> Is this lockdep slowdown expected and desirable?

It's not desirable at all.

Does the patch below fix the regression for you - or does the introduction and 
handling of ->nr_acquire hurt as well?

Thanks,

	Ingo

====================>
 lib/Kconfig.debug | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6401d325b0e..f5b40c1668ea 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1138,8 +1138,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
+#	select LOCKDEP_COMPLETIONS
 	select TRACE_IRQFLAGS
 	default n
 	help

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Johan Hovold <johan@kernel.org>
Cc: Byungchul Park <byungchul.park@lge.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	linux-mm@kvack.org, kernel-team@lge.com,
	Tony Lindgren <tony@atomide.com>, Arnd Bergmann <arnd@arndb.de>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Dramatic lockdep slowdown in 4.14
Date: Sat, 14 Oct 2017 09:26:59 +0200	[thread overview]
Message-ID: <20171014072659.f2yr6mhm5ha3eou7@gmail.com> (raw)
In-Reply-To: <20171013090333.GA17356@localhost>


* Johan Hovold <johan@kernel.org> wrote:

> Hi,
> 
> I had noticed that the BeagleBone Black boot time appeared to have
> increased significantly with 4.14 and yesterday I finally had time to
> investigate it.
> 
> Boot time (from "Linux version" to login prompt) had in fact doubled
> since 4.13 where it took 17 seconds (with my current config) compared to
> the 35 seconds I now see with 4.14-rc4.
> 
> I quick bisect pointed to lockdep and specifically the following commit:
> 
> 	28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition
> 	               of a crosslock")
> 
> which I've verified is the commit which doubled the boot time (compared
> to 28a903f63ec0^) (added by lockdep crossrelease series [1]).
> 
> I also verified that simply disabling CONFIG_PROVE_LOCKING on 4.14-rc4
> brought boot time down to about 14 seconds.
> 
> Now since it's lockdep I guess this can't really be considered a
> regression if these changes did improve lockdep correctness, but still,
> this dramatic slow down essentially forces me to disable PROVE_LOCKING
> by default on this system.
> 
> Is this lockdep slowdown expected and desirable?

It's not desirable at all.

Does the patch below fix the regression for you - or does the introduction and 
handling of ->nr_acquire hurt as well?

Thanks,

	Ingo

====================>
 lib/Kconfig.debug | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6401d325b0e..f5b40c1668ea 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1138,8 +1138,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
+#	select LOCKDEP_COMPLETIONS
 	select TRACE_IRQFLAGS
 	default n
 	help

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: Dramatic lockdep slowdown in 4.14
Date: Sat, 14 Oct 2017 09:26:59 +0200	[thread overview]
Message-ID: <20171014072659.f2yr6mhm5ha3eou7@gmail.com> (raw)
In-Reply-To: <20171013090333.GA17356@localhost>


* Johan Hovold <johan@kernel.org> wrote:

> Hi,
> 
> I had noticed that the BeagleBone Black boot time appeared to have
> increased significantly with 4.14 and yesterday I finally had time to
> investigate it.
> 
> Boot time (from "Linux version" to login prompt) had in fact doubled
> since 4.13 where it took 17 seconds (with my current config) compared to
> the 35 seconds I now see with 4.14-rc4.
> 
> I quick bisect pointed to lockdep and specifically the following commit:
> 
> 	28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition
> 	               of a crosslock")
> 
> which I've verified is the commit which doubled the boot time (compared
> to 28a903f63ec0^) (added by lockdep crossrelease series [1]).
> 
> I also verified that simply disabling CONFIG_PROVE_LOCKING on 4.14-rc4
> brought boot time down to about 14 seconds.
> 
> Now since it's lockdep I guess this can't really be considered a
> regression if these changes did improve lockdep correctness, but still,
> this dramatic slow down essentially forces me to disable PROVE_LOCKING
> by default on this system.
> 
> Is this lockdep slowdown expected and desirable?

It's not desirable at all.

Does the patch below fix the regression for you - or does the introduction and 
handling of ->nr_acquire hurt as well?

Thanks,

	Ingo

====================>
 lib/Kconfig.debug | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6401d325b0e..f5b40c1668ea 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1138,8 +1138,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
+#	select LOCKDEP_COMPLETIONS
 	select TRACE_IRQFLAGS
 	default n
 	help

  parent reply	other threads:[~2017-10-14  7:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13  9:03 Dramatic lockdep slowdown in 4.14 Johan Hovold
2017-10-13  9:03 ` Johan Hovold
2017-10-13  9:03 ` Johan Hovold
2017-10-13  9:07 ` Peter Zijlstra
2017-10-13  9:07   ` Peter Zijlstra
2017-10-13  9:07   ` Peter Zijlstra
2017-10-13  9:35   ` Johan Hovold
2017-10-13  9:35     ` Johan Hovold
2017-10-13  9:35     ` Johan Hovold
2017-10-14  7:26 ` Ingo Molnar [this message]
2017-10-14  7:26   ` Ingo Molnar
2017-10-14  7:26   ` Ingo Molnar
2017-10-14  8:11   ` Johan Hovold
2017-10-14  8:11     ` Johan Hovold
2017-10-14  8:11     ` Johan Hovold
2017-10-14 11:36   ` [tip:locking/urgent] locking/lockdep: Disable cross-release features for now tip-bot for Ingo Molnar
2017-10-16  2:04     ` Byungchul Park
2017-10-17  7:12       ` Ingo Molnar
2017-10-17  7:40         ` Thomas Gleixner
2017-10-17 14:42           ` Ingo Molnar
2017-10-17 15:03             ` Thomas Gleixner
2017-10-17 16:21               ` Ingo Molnar
2017-10-18  7:48               ` Byungchul Park
2017-10-18  5:31         ` Byungchul Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171014072659.f2yr6mhm5ha3eou7@gmail.com \
    --to=mingo@kernel.org \
    --cc=arnd@arndb.de \
    --cc=byungchul.park@lge.com \
    --cc=johan@kernel.org \
    --cc=kernel-team@lge.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.