Re: [libvirt PATCH] ci: maximize cirrus CI ram/cpu allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 21, 2021 at 11:48:17AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 21, 2021 at 06:39:07AM -0400, Andrea Bolognani wrote:
> > On Tue, Jul 20, 2021 at 04:05:22PM +0100, Daniel P. Berrangé wrote:
> > > For macOS you always get the maximum configuration by default (12 CPUs,
> > > 24 GB RAM), but for FreeBSD you get 2 CPUs, 4 GBs by default. This
> > > change increases the allocation to 8 CPUs, 8 GBs for FreeBSD.
> > >
> > > ---
> > > In theory this could make builds quicker. In practice I've not been
> > > able to measure a difference due to large variance between runs.
> > 
> > Should we actually do this? The fact that FreeBSD builds take so much
> > time is painful, but if you haven't been able to measure significant
> > improvements from maximizing the number of CPUs assigned to the VM
> > then perhaps other factors such as slow disk speed are to blame
> > instead. In fact, looking at recent jobs it looks like they mostly
> > fall in line with Linux builds...
> 
> Yeah, I'm in two minds and just sent this patch to get a second
> opinion.
> 
> I noticed the ability to configure this when switching QEMU to
> use lcitool for generating the freebsd/macos configuration.
> The increase in resources for FreeBSD VMs made a significant
> difference to QEMU build times - the difference between passing
> and hitting the job limit timeout.
> 
> Thus I'm really puzzelled why libvirt didn't see a real benefit
> when I tested it.  As you say though, FreeBSD builds are no worse
> than Linux builds, so it isn't critical for us.

I guess looking at the CPU chart in this run explains it:

  https://cirrus-ci.com/task/5496170802839552

The first 75% of the job time was using less than 1 CPU. Only
the last 3 minutes maxed out both CPUs. So adding more CPUS
will only help the last bit of the job and even then we'll
hit limits on amount of parallelism due to build dependancies.

QEMU simply has much much more stuff needing building and is
highly parallel when building, so saw a big benefit.

So this affirms that we dont really need this patch.

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 :|




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux