<div dir="ltr"><div dir="ltr">On Wed, 14 Aug 2019 at 13:36, <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:<br>
> On Tue, 13 Aug 2019 at 21:18, Richard Purdie <<br>
> <a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>> wrote:<br>
> > I had a glance at the profile output from master-next and the<br>
> > problem<br>
> > wasn't where I thought it would be, it was in the scheduler code.<br>
> > That<br>
> > is good as those classes are effectively independent of the other<br>
> > changes and hence are a separate fix.<br>
> > <br>
> > I've put a patch in -next which takes the above test to 36s which<br>
> > is<br>
> > close to the older bitbake.<br>
> > <br>
> > Could be interesting to see how it looks for others and different<br>
> > workloads.<br>
> <br>
> I just tried the same test I did yesterday with<br>
> ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it doesn't<br>
> seem to improve things much: bitbake is stuck at "NOTE: Executing<br>
> Tasks" for 15 minutes now.<br>
<br>
This might sound slightly crazy but can you try commenting out this<br>
line in runqueue.py:<br>
<br>
logger.debug(2, "Holding off tasks %s" % pprint.pformat(self.holdoff_tasks))<br>
<br>
?<br></blockquote><div><br></div><div>Even crazier is the outcome: it helped! The whole thing completed after 15m49secons (with much of the time going to the empty task spin), that's some 3 minutes slower, but certainly it's usable again.</div><div><br></div><div>I have not enabled the hash server at any point.</div><div><br></div><div>Alex<br></div></div></div>