All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Johan Hovold <johan@kernel.org>,
	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 10:11:24 +0200	[thread overview]
Message-ID: <20171014081124.GB16632@localhost> (raw)
In-Reply-To: <20171014072659.f2yr6mhm5ha3eou7@gmail.com>

On Sat, Oct 14, 2017 at 09:26:59AM +0200, Ingo Molnar wrote:
> 
> * 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?

> -	select LOCKDEP_CROSSRELEASE
> -	select LOCKDEP_COMPLETIONS
> +#	select LOCKDEP_CROSSRELEASE
> +#	select LOCKDEP_COMPLETIONS

Disabling these options this way gives me a about boot time of 17
seconds again, so yes, that fixes the problem.

Thanks,
Johan

--
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: johan@kernel.org (Johan Hovold)
To: linux-arm-kernel@lists.infradead.org
Subject: Dramatic lockdep slowdown in 4.14
Date: Sat, 14 Oct 2017 10:11:24 +0200	[thread overview]
Message-ID: <20171014081124.GB16632@localhost> (raw)
In-Reply-To: <20171014072659.f2yr6mhm5ha3eou7@gmail.com>

On Sat, Oct 14, 2017 at 09:26:59AM +0200, Ingo Molnar wrote:
> 
> * 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?

> -	select LOCKDEP_CROSSRELEASE
> -	select LOCKDEP_COMPLETIONS
> +#	select LOCKDEP_CROSSRELEASE
> +#	select LOCKDEP_COMPLETIONS

Disabling these options this way gives me a about boot time of 17
seconds again, so yes, that fixes the problem.

Thanks,
Johan

WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Johan Hovold <johan@kernel.org>,
	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 10:11:24 +0200	[thread overview]
Message-ID: <20171014081124.GB16632@localhost> (raw)
In-Reply-To: <20171014072659.f2yr6mhm5ha3eou7@gmail.com>

On Sat, Oct 14, 2017 at 09:26:59AM +0200, Ingo Molnar wrote:
> 
> * 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?

> -	select LOCKDEP_CROSSRELEASE
> -	select LOCKDEP_COMPLETIONS
> +#	select LOCKDEP_CROSSRELEASE
> +#	select LOCKDEP_COMPLETIONS

Disabling these options this way gives me a about boot time of 17
seconds again, so yes, that fixes the problem.

Thanks,
Johan

  reply	other threads:[~2017-10-14  8:11 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
2017-10-14  7:26   ` Ingo Molnar
2017-10-14  7:26   ` Ingo Molnar
2017-10-14  8:11   ` Johan Hovold [this message]
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=20171014081124.GB16632@localhost \
    --to=johan@kernel.org \
    --cc=arnd@arndb.de \
    --cc=byungchul.park@lge.com \
    --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=mingo@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.