On Tue, Aug 13, 2019 at 12:18 PM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Tue, 2019-08-13 at 10:04 +0100, Richard Purdie wrote: > > 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 :/. > > I had a glance at the profile output from master-next and the problem > wasn't where I thought it would be, it was in the scheduler code. That > is good as those classes are effectively independent of the other > changes and hence are a separate fix. > > I've put a patch in -next which takes the above test to 36s which is > close to the older bitbake. > > Could be interesting to see how it looks for others and different > workloads. >
will try it tonight > Cheers, > > Richard > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
