All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
	Alexander Kanavin <alex.kanavin@gmail.com>,
	Khem Raj <raj.khem@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)
Date: Tue, 13 Aug 2019 10:04:08 +0100	[thread overview]
Message-ID: <33bca828a78daaefc32fe497e7f244e3208bc968.camel@linuxfoundation.org> (raw)
In-Reply-To: <fcc15178e58e4ef0a8e2cf3047109bd5@xbox06.axis.com>

On Mon, 2019-08-12 at 20:26 +0000, Peter Kjellerstedt wrote:
> Comparing that build to a corresponding do-nothing build with Thud,
> the time difference matches those three minutes where I have no idea
> what bitbake is doing now that it didn’t need to do before…
>  
> Hopefully these time degradations can be solved, because the current
> state of bitbake is barely usable. We also need to look into possible
> ways to improve the cooker output when it is running the setscene
> tasks so it makes some kind of sense again.

We talked on irc and you pointed at the commit things started to go
wrong. Just to summarise things for the benefit of the list, this is
some quick testing I did:

"bitbake -p; time bitbake core-image-minimal -n"

30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
30.6s a0d941c787cf3ef030d190903279d311bc05d752
40.3s 7df31ff36892c2f9c65326b06b4c70 
42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e 
45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c 
76.9s master-next

So basically the original changes showed a 25% hit but the performance
of -next is dire.

This is with no hash equiv server configured.

It will vary depending on the target used (numbers with -sato for the
above would be interesting for comparision) and how much was or is in
sstate, they type of sstate mirror configured and so on.

I really need to focus on getting the new code functioning correctly
before we attempt to optimise but if nobody tests the new code due to
performance problems we have a different issue. We also have a scaling
problem with the hash server itself I need to fix to stop the
autobuilder throwing weird errors. I'm therefore a bit challenged on
where to start with it all :/.

Cheers,

Richard





  reply	other threads:[~2019-08-13  9:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 20:26 Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively) Peter Kjellerstedt
2019-08-13  9:04 ` Richard Purdie [this message]
2019-08-13 13:20   ` Alexander Kanavin
2019-08-13 19:18   ` Richard Purdie
2019-08-14  4:06     ` Khem Raj
2019-08-14 11:25     ` Alexander Kanavin
2019-08-14 11:36       ` richard.purdie
2019-08-14 12:08         ` Alexander Kanavin
2019-08-14 12:43           ` Alexander Kanavin
2019-08-14 12:50           ` Mikko.Rapeli
2019-08-14 12:55           ` richard.purdie
2019-08-14 14:57             ` Peter Kjellerstedt
2019-08-14 15:19               ` Khem Raj
2019-08-14 20:27             ` Alexander Kanavin
2019-08-14 21:25               ` richard.purdie
2019-08-15 12:56                 ` Alexander Kanavin
2019-08-15 13:56                   ` richard.purdie
2019-08-15 22:44                     ` Richard Purdie
2019-08-15 15:05   ` Martin Jansa
2019-08-16 10:24     ` Martin Jansa
2019-08-16 15:00       ` Martin Jansa
2019-08-16 15:54         ` richard.purdie
2019-08-16 17:22           ` Martin Jansa
2019-08-19 21:23             ` Martin Jansa

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=33bca828a78daaefc32fe497e7f244e3208bc968.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alex.kanavin@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    --cc=raj.khem@gmail.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.