Currently, we manually twiddle each known memory hog recipe with jobs = N that matches whatever system it is being compiled on.
This proposal is about adding a per_job_mem_gb key that, when present and strictly greater than zero, will check the currently available memory and divide it with per_job_mem_gb and then set %JOBS% to the floor of that value.
Code with this logic has been in limited production in the Serpent onboarding scripts for a couple of years now.
The benefit to Solus is that we can then set the proposed per_job_mem_gb key for known memory hogs and just have it work on both local systems and the builder going forward, with ypkg auto-handling setting the number of jobs accordingly.
Currently, we manually twiddle each known memory hog recipe with
jobs = N
that matches whatever system it is being compiled on.This proposal is about adding a
per_job_mem_gb
key that, when present and strictly greater than zero, will check the currently available memory and divide it withper_job_mem_gb
and then set%JOBS%
to the floor of that value.Code with this logic has been in limited production in the Serpent onboarding scripts for a couple of years now.
The benefit to Solus is that we can then set the proposed
per_job_mem_gb
key for known memory hogs and just have it work on both local systems and the builder going forward, withypkg
auto-handling setting the number of jobs accordingly.