<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 8, 2020, 6:24 PM chris.laplante--- via Openembedded-core <<a href="mailto:openembedded-core@lists.openembedded.org" target="_blank" rel="noreferrer">openembedded-core@lists.openembedded.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<br>
> > > Anecdotally, we are running Zeus for nightly builds with three<br>
> > > multiconfigs. I cherry-picked your "bitbake: fix2" and "bitbake:<br>
> > > fixup" patches and haven't seen any of the BB_UNIHASH errors since.<br>
> > > Granted it's only been a week. But before that, hash equiv +<br>
> > > multiconfig was unusable due to the BB_UNIHASH errors.<br>
> ><br>
> > That is a really helpful data point, thanks. I should probably clean up<br>
> > those bitbake patches and get them merged then, I couldn't decide if<br>
> > they were right or not...<br>
> ><br>
> <br>
> I just picked all your pending changes out of master-next into our<br>
> local patch queue - will let you know how it looks when it's finished<br>
> cooking!<br>
<br>
There are two small issues I have observed. <br>
<br>
One is occasionally I get a lot of undeterministic metadata errors when BB_CACHE_POLICY = "cache", multiconfig, and hash equiv are enabled. The errors are all on recipes for which SRCREV = "${AUTOREV}". It doesn't always happen. But it did just now when I rebased our "zeus-modified" branch onto the upstream "zeus" branch, to get the changes starting with 7dc72fde6edeb5d6ac6b3832530998afeea67cbc. <br>
<br>
Two is that, sometimes "Initializing tasks" stage appears stuck at 44% for a couple minutes. I traced it down to this code in runqueue.py (line 1168 on zeus):<br>
<br>
# Iterate over the task list and call into the siggen code<br>
dealtwith = set()<br>
todeal = set(self.runtaskentries)<br>
while len(todeal) > 0: <br>
for tid in todeal.copy():<br>
if len(self.runtaskentries[tid].depends - dealtwith) == 0:<br>
dealtwith.add(tid)<br>
todeal.remove(tid)<br>
self.prepare_task_hash(tid)<br>
<br>
When I instrument the loop to print out the size of "todeal", I see it decrease very slowly, sometimes only a couple at a time. I'm guessing this is because prepare_task_hash is contacting the hash equiv server, in a serial manner here. I'm over my work VPN which makes things extra slow. Is there an opportunity for batching here? <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Batching is hard because the hashes you request might depend on hashes previous received from the server. It might be possible to figure out these dependencies and submit multiple batch requests, but this would require some work in the code. Another option would be to have some multi-level caching scheme where you can have a local database that mirrors your centralized server.</div><div dir="auto"><br></div><div dir="auto">If you have any ideas on how to make it faster, we would love to hear your opinion :)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Chris<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" rel="noreferrer noreferrer" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div></div></div>