All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Johan Hovold <johan@kernel.org>,
	Byungchul Park <byungchul.park@lge.com>,
	Ingo Molnar <mingo@kernel.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,
	Thorsten Leemhuis <regressions@leemhuis.info>
Subject: Re: Dramatic lockdep slowdown in 4.14
Date: Fri, 13 Oct 2017 11:35:16 +0200	[thread overview]
Message-ID: <20171013093516.GB17356@localhost> (raw)
In-Reply-To: <20171013090744.lvvc66qexmomsd5f@hirez.programming.kicks-ass.net>

On Fri, Oct 13, 2017 at 11:07:44AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 13, 2017 at 11:03:33AM +0200, Johan Hovold 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?
> 
> Expected yes, desirable not so much. Its the save_stack_trace() in
> add_xhlock() (IIRC).
> 
> I've not yet had time to figure out what to do about that.

Thanks for confirming. Do you think it makes sense to track this as a
4.14 regression to avoid having others spend time on tracking this down
meanwhile? (Adding Thorsten on CC.)

Johan

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: Fri, 13 Oct 2017 11:35:16 +0200	[thread overview]
Message-ID: <20171013093516.GB17356@localhost> (raw)
In-Reply-To: <20171013090744.lvvc66qexmomsd5f@hirez.programming.kicks-ass.net>

On Fri, Oct 13, 2017 at 11:07:44AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 13, 2017 at 11:03:33AM +0200, Johan Hovold 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?
> 
> Expected yes, desirable not so much. Its the save_stack_trace() in
> add_xhlock() (IIRC).
> 
> I've not yet had time to figure out what to do about that.

Thanks for confirming. Do you think it makes sense to track this as a
4.14 regression to avoid having others spend time on tracking this down
meanwhile? (Adding Thorsten on CC.)

Johan

WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Johan Hovold <johan@kernel.org>,
	Byungchul Park <byungchul.park@lge.com>,
	Ingo Molnar <mingo@kernel.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,
	Thorsten Leemhuis <regressions@leemhuis.info>
Subject: Re: Dramatic lockdep slowdown in 4.14
Date: Fri, 13 Oct 2017 11:35:16 +0200	[thread overview]
Message-ID: <20171013093516.GB17356@localhost> (raw)
In-Reply-To: <20171013090744.lvvc66qexmomsd5f@hirez.programming.kicks-ass.net>

On Fri, Oct 13, 2017 at 11:07:44AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 13, 2017 at 11:03:33AM +0200, Johan Hovold 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?
> 
> Expected yes, desirable not so much. Its the save_stack_trace() in
> add_xhlock() (IIRC).
> 
> I've not yet had time to figure out what to do about that.

Thanks for confirming. Do you think it makes sense to track this as a
4.14 regression to avoid having others spend time on tracking this down
meanwhile? (Adding Thorsten on CC.)

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>

  reply	other threads:[~2017-10-13  9:35 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 [this message]
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
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=20171013093516.GB17356@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=regressions@leemhuis.info \
    --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.