<div dir="ltr"><div dir="ltr">Thanks for the feedback. <br><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"13","compose-window":{"secure":false}}"></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2019 at 5:32 AM Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2019-07-08 at 14:27 -0400, Alan Kozlay wrote:<br>
> We're looking for things we can do to improve the multiconfig build<br>
> time.<br>
> <br>
> Even on our build servers it still takes a long time.<br>
> For instance, our build servers each have 64 core, 128G RAM with 4<br>
> NVMe SSD HDs in a striped raid (all configured with bells and<br>
> whistles to make it super fast).<br>
> A full fresh build on one of those servers still takes 6 hours.<br>
<br>
Given we have no idea what these mulitconfigs are, how much overlap<br>
there is or how you're running it, its hard to know whether 6 hours is<br>
good or bad.<br>
<br>
> I need to also clarify that we do indeed define different<br>
> DISTRO_FEATURES between multiconfigs, so multiconfig is necessary.<br>
> <br>
> (1) We're attempting to use the ccache (via ccache.bbclass), but it's<br>
> causing some build errors that we're investigating.<br>
<br>
That shouldn't cause errors and would likely be some ccache problem.<br>
<br>
> (2) Can we at least set the root native work directory to be the same<br>
> for all multiconfigs?<br>
<br>
It depends if the configurations are different or not. WORKDIR isn't<br>
your problem here, you really need the builds to have the same sysroot-<br>
components dir for the native case too, else this won't work. Its more<br>
about the output from the task than the directory they were built in.<br>
<br>
> Would each multiconfig honor the previously built native tools?<br>
> Or, would it just rebuild them, anyway?<br>
> Is this safe or tested or supported?<br>
<br>
multiconfig is configured so that if it sees overlapping stamp files it<br>
would handle that correctly. The tricky part is you'd have to split<br>
some directories which aren't usually split such as sysroot-components. <br>
I've never seen that attempted and am not sure if it would work or not.<br>
<br>
> (3) We're considering a network shared sstate-cache. But it's not<br>
> entirely clear if a multiconfig build is benefited by the sstate-<br>
> cache directory.<br>
> Under what circumstances does a multiconfig leverage sstate-cache<br>
> when building for another multiconfig?<br>
<br>
Right now today for a single multiconfig build it won't.<br>
<br>
> What if the recipe would be affected by a change in DISTRO_FEATURES<br>
> between multiconfigs?<br>
> Are native packages included in the sstate-cache or just target<br>
> packages?<br>
<br>
native and target are included in sstate-cache.<br>
<br>
> We welcome all thoughts and ideas.<br>
<br>
With current bitbake you'd be best off splitting your multiconfig build<br>
into two parts a first stage where you build common shared components<br>
and a second where you leverage them.<br>
<br>
I appreciate that isn't a good solution but its what will work right<br>
now.<br>
<br>
The initial work in adapting bitbake to better handle situations like<br>
this is being done, as we speak and there are patches starting it in<br>
master-next.<br>
<br>
Right now those patches also won't change anything for you, they re-<br>
architect the codebase so we have a chance of implementing what you<br>
want. It is however at least a start. I'm working on this effectively<br>
alone with the day to day patch review, email and bugs to handle at the<br>
same time :(. As a project we know this is important but we struggle to<br>
find people willing to contribute development resources to make these<br>
kinds of changes happen.<br>
<br>
Next step is to write a regression test suite for runqueue. Once I've<br>
done that I'll start to think about optimisation work.<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span><div><div dir="ltr"><div><div>Alan Kozlay<br></div><div dir="ltr">VES Solutions, LLC<br><span>Alan Kozlay <alan.kozlay@ves.solutions></span><div>DESK 443-595-7734<br></div><div>CELL 443-752-0323</div></div></div></div></div></span></div></div></div></div></div>