Cpumode used to adjust cpu speed -- does it do same for a guest vm?

I use cpumode app to change cpu speed up and down. Setting to “performance” does seem to run things faster.

cpumode is used on host device. Will changing cpu to “performance” in host also adjust speed for a vm running on this host.
Or, do I need to install cpumode in the guest vm and run it there to get any speedup.

Also, can cpumode running on a guest increase speed of a vm if the host is still at normal speed?

A lot I don’t know about operation of vm’s but I use a bunch of them.
Perhaps, this is a virtualization question and should be moved there.

thanks, tom kosvic

Probably depends on what kind of virtualization you’re using, but ultimately, the CPU speed is the CPU speed - and you can’t get a CPU performance gain in the guest without changing the performance characteristics of the host’s CPU.

You can’t get something for nothing. :wink:

Also, what is the specific app you use - where did you get it, and what’s it called? (cnf cpumode didn’t find that particular command in the Tumbleweed standard repos)

I can not recall when/where I got cpumode. It changes between two settings; powersaver and performance. You need root to run cpumode . It is in /usr/local/sbin/.

It sounds rational to me that you can’t get “performance” mode in a guest vm w/o performance being set in the host. But, could there not be independent cpu settings within the vm. I use qemu libvirt vms. Conceivably, to me, a vm might have separate memory management and could run at different speed from the guest.

Also, do you need to set the guest vm to performance additionally or does the vm automatically run in performance mode?

I do belive I compiled cpumode from this reference:

https://unix.cafe/wp/en/2020/07/toggle-between-cpu-powersave-and-performance-in-linux/

At some time in the past.

There’s a command on my system that is probably the one you should use - cpupower - that has a number of options.

It depends on a kernel driver, which isn’t present in my VMware systems (which makes sense). So it would use whatever the host is set to.

The VM will use the host’s settings, almost certainly guaranteed.

Whether the CPU can be controlled or not as a guest depends on the type of virtualization that’s done; typically with emulators, you can control the speed of the emulated CPU (for example, a Commodore 64 running at 1 MHz would be an emulated 6502 processor, and having it run at 4 GHz would render it unusable, so a governor is used in the emulator to slow the emulated CPU down to an appropriate speed.

Paravirtualization, though, works differently.

What I’d suggest is giving it a try and see what happens.

OK, so you don’t think a vm could handle the cpus it has control over completely independently from those that the host controls. That is what I am not sure of.

I guess I will get some app that would provide a speed number after running for some time period and run it on the host and a guest separately and simultaneously with power variations in a test program. Will take me a while. Perhaps I can find something in phoronix test app.

What kernel driver is needed to run cpumode or cpupower in the vm so I can find how to add it if needed and make that also a test parameter?

I just thought there was an obvious answer to this question that someone could give me. Now I need a test program.

I’m interested in this topic because I run a gentoo vm and sometimes a system update takes 2 days to run with 6 cpus on a pretty fast i7 chip. That affects everything else going on on my other 6 cpus. I’d like to mitigate that somehow.

thanks, tom kosvic

It seems logical that controlling the CPU from within the VM wouldn’t make sense - certainly that control wouldn’t be independent of the host, because the CPU is the CPU. It might be allocated a specific number of CPU cores.

If there even is a driver, it would probably depend on the virtualization solution. In my host, I see it’s the “intel_pstate” driver (cpupower frequency-info tells me that). Inside a VMware VM, it says there is no driver instaled and no governors available (as a consequence).

This seems to be a good explanation. Chances are that the CPU capability isn’t virtualized, so isn’t available at all.

In my experience, this is not a CPU-bound process, but a memory-bound process. I just ran a bunch of updates on VMs (Gentoo isn’t one of the VMs I currently run, but I have a couple Windows VMs and several openSUSE VMs), and I find that if the memory isn’t sufficient, the guest starts swapping, and the I/O resulting from that tends to bury the performance of the system.

I would look at the memory allocated to the system and the host’s loadavg (/proc/loadavg) while the update is running and see what that tells you. Updates tend not to be CPU-bound, so messing with the CPU isn’t likely to do it.

What’s probably happening is the loadavg is going up, and that’s causing CPU performance issues because processes are entering an iowait state, and the CPU can’t process not because it isn’t fast enough or the governor isn’t working in performance mode, but because the CPU is having to wait for I/O to finish before it can continue, and it’s being blocked as a result.

iostat (run as root) can also be helpful for determining if that’s the cause, but in almost all cases in a VM, this will be caused by insufficient memory (indeed, updating a Win11 VM yesterday, I ran into this exact issue - only 8 GB of RAM allocated; bumped it to 16, and it stopped having issues).

@hendersj I set my Win 11 Pro to 12 cores and 32GB of ram, that seem to make it behave…

I have a gentoo libvirt vm emerge (update) running as we speak with 6 cpus. It has 8 gig memory. The memory use (using system manager on the vm) is cycling but is a max of about 60%. Swap use is 500mb used out of 6 gig and not changing. The individual cpus are cycling but are reaching 100%.

My host is at normal cpu speed; not performance setting.

I don’t tend to use it for much of anything, so 16 GB and 4 cores (IIIRC) has been sufficient here to run Windows Update…but we digress. :slight_smile:

That’s probably not enough. But I would look at loadavg as well to see what the issue is. It really sounds like an I/O bottleneck is putting the CPU in iowait, as that would look like high CPU usage.

How much memory in the host?

The openSUSE host has 32g of memory. It has 12 cpus. With the gentoo vm still running, the memory use is 51% (16 gb). Usage is relatively constant. Swap is 2gb with 40% use and not changing.

I think increasing cpu speed is my only way to decrease gentoo update times using external resources. I am also looking at adjusting gentoo parameters to decrease time by optimizing the gentoo internal processes.

@tckosvic does the VM report the same CPU as the host or something different?

What do you see with iostat 1 while running the update?

System updates are generally not CPU-bound. They’re generally I/O-bound.

I would look at the %iowait value in particular during the update. As I said, if the CPU is waiting on I/O, it will look busy, even though it’s not - a CPU that’s waiting on I/O doesn’t show as “idle” because it isn’t - it’s busy, but it’s waiting for slower I/O subsystems to finish what they’re doing so it can continue - I/O can be blocking the CPU.

Messing with the CPU governor is something I’ve never needed to do in 20+ years of working with virtual machines. Never in the host, never in a guest.

Are you running a GUI inside the Gentoo VM?

12 hrs later, gentoo emerge (update) is still running and compiling.

I tried “iostat” but it is not installed in the gentoo vm.

gentoo compiles each package on your machine. It downloads only source code: not binaries. One module, e.g., qtwebengine, has 31,000 separate compilations. gentoo updates are definitely not limited by download time. compilation time dwarfs download time.

I run many guis on gentoo but at present I am only running a terminal.

I get my jollies compiling stuff. That is only reason I have gentoo as vm. You do get the latest though. It has downloaded kernel 6.12.6, for example as part of this process.

I post on gentoo forum re: update times also.

Regarding my initial question, I think I will look at gamer info to see if overclocking works in a vm and/or whether it needs to also be set in the vm.

thanks all, tom kosvic

Here’s data from iostat 1 run on openSUSE host. gentoo update is still running.

(base) tom@mydesktop: / $ iostat 1
Linux 6.4.0-150600.23.30-default (mydesktop)    12/21/2024      _x86_64_        (12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.09   43.75    4.21    0.23    0.00   31.72

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              17.35       110.59       608.36   46427371  255388606
sdc               0.01         0.04         0.00      18857        504
sdb              12.94        59.66         4.34   25043994    1823896

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.36    0.00    3.12    0.59    0.00   57.93

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              24.00       332.00         0.00        332          0
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          42.04    0.00    2.86    0.34    0.00   54.76

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              61.00         0.00       396.00          0        396
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.24    0.00    3.63    0.17    0.00   55.96

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               2.00         0.00        52.00          0         52
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.68    0.00    3.73    1.69    0.00   53.90

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              78.00         0.00      8888.00          0       8888
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.59    0.00    2.71    0.00    0.00   58.69

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.48    0.00    3.21    0.00    0.00   58.31

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.00         0.00        68.00          0         68
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          40.40    0.00    2.95    0.00    0.00   56.65

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.82    0.00    2.94    0.17    0.00   58.07

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               2.00         0.00        56.00          0         56
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          39.26    0.00    2.78    1.18    0.00   56.78

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              25.00         0.00      2900.00          0       2900
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          39.74    0.00    3.32    0.00    0.00   56.94

Device             tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
sdc               0.00         0.00         0.00          0          0
sdb               0.00         0.00         0.00          0          0

Compiling is both memory and I/O intensive. While it doesn’t look like the host is seeing iowait as a problem, I would still be inclined to increase the RAM in the VM system.

Again, 20 years worth of running VMs, I’ve never had to mess with the CPU governor to make a VM run faster. I would probably look to install iostat in the VM to see if it’s reporting anything at all.

I did remember that Gentoo compiles everything from source - and that is a long way to build a Linux distribution regardless of the platform. I’m doing an install of Gentoo in VMware today just because it’s been so long since I installed that distro.

Overclocking won’t work in the VM, because, again, you can’t tell the VM’s CPU to run faster than the host’s CPU - it’s the same CPU. Overclocking is not likely to help significantly with compilation, because (again) compilation is not generally CPU-bound. It takes memory and it takes I/O bandwidth.

OK, doing some testing here, and I had forgotten how CPU intensive it could be with compiler optimizations. Memory and I/O are important, but I’m seeing while compiling the kernel in a 4-CPU VM that the host is showing that process using as much CPU as it can get.

Memory and I/O are important, but with large compilation jobs like the kernel, gcc, and other such compilations that build optimized code, more CPU is certainly bettter.

Now that said, here’s what I’m finding:

  1. The CPU governor doesn’t really make much of a difference. In powersave mode, I’m seeing the 4 CPUs allocated to the VM (plus 1 additional) on the host running at 4.1 GHz on my system (an i9-10980XE with 36 cores).
  2. The host loadavg (1 minute) is about 7.7 during compilation; normally it hangs around 4 while just doing normal stuff. /proc/loadavg inside the VM shows about a 3.8 for the past minute during compilation, which tracks.
  3. The VM has 8 GB of memory allocated to it. Has about half a GB free, with virtually no swap in use (using cat /proc/meminfo to see general usage info in the VM)

You could try adding additional CPUs to the VM to see if that helps. Adding another 2 GHz CPU (or whatever speed your i7 runs at; my i9 is a 4.6 GHz chip per core at max speed). Eeking out another few MHz per core isn’t going to speed things up significantly enough to drop your update’s build time from what you’re seeing, but adding another full core or two is likely to give it a more significant bump on compilation time. Half your memory is in the VM, IIRC, and pushing more into it might help, or it might cause swapping in the host (it depends on how memory is allocated - VMware does some funky stuff to not reserve the full amount of memory configured unless it’s used - though I see during the compilation of the kernel that it’s maxed out on the host).

I hadn’t initially recalled that emerge/portage built from source, and that does change things a bit, which is why I said that system updates aren’t CPU bound - building from source is a place where that can be different, depending on what’s being built and how much optimization the compiler is doing.

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

@hendersj,

I am absolutely knocked-over by your efforts. You put in a lot of work. If you didn’t have gentoo already installed, that takes some people many hours just to get that done. Running the test program also took a lot of time.

The gentoo vm emerge I was running while we were conversing completed after 19 hrs with 6 cpus measured by “time” process. I will continue to try to get that down. I do have threads going on gentoo forum on this issue. I think some of the threads you saw on the gentoo forum were probably mine.

Prior to trying similar efforts to yours, I have been looking at my speedup code cpumode (that was compiled from internet source) vs the cpupower that is in the openSUSE repos. I did install cpupower. I was setting up to run some comparisons to see if the speedups were similar. I think they will be. cpupower has broader functionality than cpumode. I take much longer than you. I am 84 and neurons/fingers aren’t very dexterous any more.

Need clarification of your table.
CPUs refers to to the number of cpus allocated to the vm, I believe.
Cores per CPU is an unknown parameter to me. I never knew you could change that. How is that done. I need to investigate that or is it only for i9 chips?

I do see 70% improvement between 16 cpus vs 4 cpus assigned to the vm. I do need to understand the Cores per CPU though. It looks like 16 cpus with 1 Core per CPU is about 20% worse than 4 cpus cwith 4 cores per cpu. Changing cores per cpu from 4 to 1 looks like the biggest part of the 70%. I might give a couple percent to host speed up.

I concur with the observations you made from your data. The conclusions might help some openSUSE users of vms. As a broken down engineer though, I will need to replicate your conclusions.

thanks for the efforts. I will bump my gentoo libvirt vm up to 8 cpus. I will continue to optimize the gentoo emerge process. As I see anything additional, I will post.

tom kosvic