I’ve just run several tests after unpacking and configuring a virtual disk partition in VMware Workstation.
Building the kernel with various CPU configurations - the build failed each time (a problem with .btf.vmlinux.bin.o, probably need to install a package to get it to build properly, but that it failed in the same place makes the data useful anyways):
All times are the “real” time values from the ‘time’ command used in running emerge --ask sys-kernel/gentoo-kernel
.
CPUs |
Cores per CPU |
Host CPU Governor |
Other Options |
“Real” time (from bash ‘time’ command) |
16 |
1 |
powersave |
N/A |
23m43.685s |
4 |
1 |
powersave |
N/A |
70m47.475s |
4 |
4 |
powersave |
N/A |
19m13.521s |
4 |
4 |
performance |
Virtualized VTG-x/EPT, CPU Performance Counters, IOMMU |
18m46.711s |
4 |
4 |
performance |
Virtualized VTG-x/EPT, CPU Performance Counters, IOMMU, --quiet-build added to command |
23m40.433s |
|
|
|
|
|
As you can see, the number of CPUs makes the biggest difference. The governor didn’t substantially change it, and neither did virtualizing various CPU features.
The times vary slightly because I was doing other things on the system while this was running. All of the tests were done with a full-screen terminal window run over SSH. I monitored host CPU usage (as expected, CPU utilization spiked on the assigned processors to ~100% for the duration of the build, regardless of the governor setting in the host).
Performance increased by adding CPUs, but not in a linear fashion (ie, speed of 4 CPUs with one core per CPU was not 1/4 of 16 CPUs or 4 CPUs/4 cores - it was roughly 1/3).
Each CPU in use showed a frequency of roughly 3.8 GHz for each spot check (additional CPUs showed spikes as well, depending on what else I was doing while it was running). I monitored the VMware machine with htop
as well, and the CPU% figure aligned with what I expected based on the CPU usage (1400-1600% utilization with 16 CPUs or cores, 300-400% with 4 CPUs/1 core each).
The VM showed consistently that each CPU’s max speed was 2999.999 MHz, regardless of the governor setting. No governor was available in the VM. I suspect that VMware is not able to use ‘turbo’ settings available on the CPU, and that’s why the max is capped at 3 GHz. Either that, or they reserve some for overhead.
What I would do is talk with the Gentoo folks about how to minimize the impact of updates on your host - there are options like restricting the number of concurrent build jobs, or to limit the number of jobs based on the loadavg (which would affect the host as well, since the guest loadavg would add to the host’s loadavg).
But large updates of an OS that builds everything from source are going to take time. I found a number of reddit threads from people asking about install times and update times, and while “it depends” figures heavily into how long it takes to install/update (it depends on what you install/update, speed of system, memory, I/O bandwidth, etc), initial install times of 2 days or more are not unusual, and updates that include major subsystem updates cause a lot to be recompiled, and that takes time.
Some Gentoo expertise will probably help you more with reducing the impact on your host system during the update, as well as figuring out how to reduce the installation of unnecessary packages, which would increase update time with no significant benefit (why update packages you’re not actively using?).
I don’t think eeking out another 200 MHz from your CPU by overclocking or trying to get a performance governor working in the VM is going to alleviate the problems you’re seeing. A 2-day update process might be reduced by 30 minutes - probably not really enough to make it worth chasing down - I’d look for configuration options that have more impact within the Gentoo installation itself - such as packages that are installed but aren’t needed. If it takes 10 minutes to build, say, tracker, but you aren’t using it…Save the 10 minutes with every update and remove it. Not using Libreoffice base? Why update it each time - just work out how not to install it in the first place. Probably another 15 minute savings.
Just remember that nothing you do in the guest is going to let the guest exceed the performance characteristics of the host system. Ever. You can’t get something for nothing here. VMs are always going to have some performance overhead (though IME with something like VMware or similar hypervisors, the overall performance overhead can be relatively small).
Also remember that when a major system component updates - kernel, your desktop environment (especially if it’s KDE or GNOME), there’s going to be a pretty significant amount of time updating - especially for a DE, since all the apps are likely also being updated for a major release.