>>>>> On Wed, 05 Jan 2022, Sam James wrote: >> On 5 Jan 2022, at 08:28, Ulrich Mueller <u...@gentoo.org> wrote: >> >> Where does this number 2 GB come from? The amount of RAM strongly >> depends on the programming language and other factors, so I don't >> believe that there's one number that can be used for everything. >> (If only considering C and C++ 2 GB seems to be excessive, i.e. it >> will limit parallel build more than necessary. When linking, the number >> may be _much_ larger.)
> This is essentially "common law" (or "common lore" if you like!) and > is well-accepted as a good rule of thumb. Well, if the 2 GiB was a universal constant then it would be valid for _all_ builds, not just the random subset inheriting check-reqs.eclass. > The number being larger doesn't really make any difference here; > the point is to help in cases where we're pretty sure there's going > to be a problem (only users of check-reqs.eclass, and we can > Introduce a variable to give ~RAM per job too if needed). Yeah, having the ebuild specify an estimate for the average memory usage per job would be more correct. These are all band-aids however. What we would really need are options like GNU parallel's --memfree and --memsuspend. > This is also about reducing the number of support queries about > builds which failed for trivial reasons, as someone who has to handle > quite a lot of those (until such a time as we can implement better > detection, but this is also a generally nice UX improvement -- as > per what Florian/flow said). But it would defeat the YAFIYGI principle that we commonly apply. :) Ulrich
signature.asc
Description: PGP signature
