On Thu, 25 Jul 2019 at 16:39:38 +0300, Adrian Bunk wrote: > On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote: > > The only thing it did not have was more than one CPU, but AFAIK that's > > not something that may be considered as a misconfiguration. > > For CPU-bound tasks like package building I would consider this build > environment a misconfiguration.
I can see your point, but some cloud-based automated build environments that I've used at work only provide one vCPU per build. I believe this is done because builds typically don't parallelize perfectly (a build that takes 10 minutes on one core will usually take more than 5 minutes on two cores, because there are single-threaded bottlenecks like the linker or documentation toolchains), so if you have a lot of packages to build, it's a more efficient use of limited resources to build two packages with parallel=1 on one core each than to build a single package with parallel=2 on two cores. This seems like it would apply equally well whether your limited resource is the money you pay for cloud VM instances, or the number of physical CPUs available in your own non-cloudy VM host. (Of course, if you're optimizing for latency rather than throughput, to get each new version deployed and tested as quickly as possible, then the opposite is true and it's better to sprint through each package as fast as possible on as many cores as you can get - it's a question of priorities.) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924325 does look like something I've encountered in my day job, although we worked around it by disabling Ada to bypass the problematic part of the build (we don't actually have any need for Ada in that environment, so speeding up the build was welcome) rather than by adding more cores. smcv
