10:24 <Tyaku> Hello, My company want to build a "buildserver" for our yocto projects. I found on many forums and yocto list, that the recommanded is "2Gb of RAM per virtual core", But I don't see any mention of it in Yocto documentation, did someone have the source of this affirmation ?

10:25 <Tyaku> https://docs.yoctoproject.org/ref-manual/system-requirements.html : This doc only says: "You will manage to build an image such as core-image-sato for the qemux86-64 machine with as little as 8 Gbytes of RAM on an old system with 4 CPU cores, but your builds will be much faster on a system with as much RAM and as many CPU cores as possible."

10:28 <neverpanic> That recommendation comes from experience. Typically C++ compilers need around that much, if you have less memory per core, you'll see a lot of paging and the builds will slow down overall, unless you limit the parallelity (but then you wouldn't need as many CPU cores)

10:30 <neverpanic> Some 5 years ago, we used 40 core Xeon CPUs with 192G RAM to build, and that left some headroom for putting some build artifacts into a tmpfs in RAM, which can also speed things up (although speeds of SSDs have gone up since)

10:38 <paulg> A lot of it also depends on exactly what you intend to build. Within the last 1-2 years, dependencies have made it harder to avoid really large packages like rust/clang/llvm.

10:39 <paulg> These really have a large footprint and chew up large amounts of RAM.

10:40 <neverpanic> (doesn't help that clang and llvm are c++)

10:41 <paulg> The other big factor is the size of your company's team -- i.e. is it just you that will be using this machine, or will it be a shared resource with multiple team members trying to use it at the same time?

10:42 <neverpanic> unless your engineers aren't doing a lot of yocto builds or their salaries are very cheap, throwing hardware are the problem is probably cheaper than a lot of sharing, though.

10:42 <paulg> rust/clang/llvm pretty much put the nail in the coffin for 8G machines, even with just a single user, and very conservative job/task settings.

10:44 <paulg> For a single user COTS machine, I'd consider 32G the absolute bare minimum, and go with 64G if you can.

10:52 <RP> Tyaku: that recommendation stands but 8GB is probably too low now we have heavier use of llvm in there and larger c++ projects

10:52 <mcfrisk> RAM per CPU thread ratio depends on what is compiled. Sadly it's not at all about speed but avoiding kernel oom killer killing processes during build time when some big C++ based projects are being compiled. Default parallel settings only count the cores and ignore the amount of RAM. If your workload triggers oom killer, then reducing parallel settings is needed until there is enough physical RAM to handle

10:52 <mcfrisk> the linking steps.

10:52 <RP> I'd agree 32 is the realistic minimum

10:52 <RP> agodard: we should probably update 8GB to 32GB

10:55 <mcfrisk> for speed, measure first. performance co-pilot or similar tools can nicely show how builds behave and use CPU, memory, disk IO and network resources. Best case sstate cache builds are bound to IO, especially slow writes. Worst case builds are heavy on CPU and RAM. 'normal' development builds are a mix of all those.

11:19 <mathieudb> AdrianF: RP: Turns out the b4 issue we saw this morning is fixed in master branch, but not released

11:19 <mathieudb> https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=cc2d6bfbc6d2b819d8d291c3b7470642893d69fa

11:20 <mathieudb> So I guess I will just try to be more careful or switch to master until we get a new version

11:35 <RP> mathieudb: fair enough, at least it is fixed and known about

11:37 <agodard> RP: thanks for the heads up. we might need to update the minimum required disk space too, I'll check that as well

11:51 <Tyaku> thanks for your responses. What I understand is that there is no real recommandation from Yocto about the RAM memory, except the 8Gb minimum which should be changed to 32Gb. And the main issue is mainly to make sure that the OOM doesn't kill the compiler during the build (when we are building on all cores, huge projects).

11:52 <Tyaku> When we say 2GB per core, we realy talk about core or threads ? Because 1 core = 2 threads.

11:53 <Tyaku> We are a small team, we wuld like to build our yocto project automatically with gitlab CI CD

11:59 <mcfrisk> Tyaku: per thread, processes get started per thread, and memory usage of few large linking processes is the problem

12:01 <RP> agodard: thanks

14:29 <vvn> hi there -- how do you guys usually deal with a machine supporting different boot mediums (e.g. eMMC, SD, flash, which require different binaries)?

14:31 <vvn> Do you go with specific image recipes (kinda against the orthogonality of yocto), different machine configuration (duplicates a _lot_ of machine-specific packages), or multiconfig (significantly increases the parse and build time)? or something else?

14:35 <vmeson> new unassigned bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15926 Branch display on console can be misleading -- triage meeting.

15:42 <RP> reatmon: scarily, meta-ti is taking 4.5 hours to test according to: https://autobuilder.yoctoproject.org/valkyrie/#/builders/85/builds/538 :/

15:42 <RP> reatmon: I'm hoping fixing the failure "resolves" that!

15:48 <vvn> (maintaining different templateconf directories is another solution to what I was referring to)

22:28 <RP> First all green master-next builds in ages! :)