Re: [PATCH 2/3] ci: do not use #processors+1 jobs, #processors is enough

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, May 18, 2021 at 02:30:04PM +0200, Paolo Bonzini wrote:
> On 18/05/21 12:49, Thomas Huth wrote:
> > > 
> > > -    - JOBS=$(expr $(nproc) + 1)
> > > +    - JOBS=$(nproc || echo 1)
> > 
> > The basic idea of the "+ 1" was to make sure that there is always a
> > thread that runs on a CPU while maybe another one is waiting for I/O to
> > complete.
> 
> Ah, I see.  It doesn't make much sense for "make check" jobs however, which
> is where I wanted to get with the next patch.
> 
> I'm not sure it's even true anymore with current build machines (which tend
> to have a large buffer cache for headers) and optimizing compilers that
> compilation is I/O bound, so I'll time the two and see if there is an actual
> difference.

I'd be surprised if you can measure any statistically reliable difference
at all wrt public CI. I've tried measuring CI performance for small changes
and found it impossible in short time frames, as the deviation between runs
is way too large. GitLab CI speeds tend to slow down as the day goes on and
US wakes up, so by time you run QEMU CI a second time in the day, it will
be slower. They clearly overcommit resources on the cloud host so you're
at the mercy of whatever else is running.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|