@tckosvic Linux is very good for cpu utilization on the host when running vm’s, you might even be able to allocate more, just keep an eye on the host load… I normally allocate one (1) core with two (2) threads, but you should also be able to allocate a specific cpu core/threads to use as well(?) I’m just using libvirt/kvm where there is a plethora of cpu options…
One note thusfar related to my initial query.
“cpupower” from openSUSE repos is giving about 4% speedup in read/write transfers using differing block sizes and total transfer sizes. This is by setting between powersaving and performance. Tests done using sysbench from openSUSE repos. I don’t consider this even significant.
cpumode as compiled from internet is giving zero to negative speedups. I will remove this.
Will also test other computational speeds with phoronix or equivalent.
@tckosvic Also look at shedutil (default for Tumbleweed) https://docs.kernel.org/scheduler/schedutil.html
I did see the cpu settings in libvirt/qemu that you referred to. I had no idea these were available. Will play with these some.
I think hendersj must have been referring to threads per core in his table and referring to it as “cores per cpu”. Both terms are new to me.
thanks, tom kosvic
This is a configuration in VMware Workstation - I can elect to have 4 CPUs with 4 cores (for example) or 16 CPUs with 1 core - in both cases, it’s a total of 16 cores. From looking in /proc/cpuinfo
, the counts are the same.
I don’t know if libvirt has a similar capability or not; I’ve been a VMware user since version 2.x, and it’s generally been my preferred virtualization solution since then (with a few forays into Xen and VirtualBox).
Ideally, I’d run the tests multiple times, and resolve the compilation error to get better data - that 20% difference between 4/4 and 16/1 (CPUs/cores per CPU) may be an outlier.
Multiple core CPUs have been around for a while - about 10 years ago, I purchased an AMD Atheon system with a dual-core CPU for a contract I was working on that required multiple cores (a project that got me really familiar with how Linux kernel resources are managed - sadly, the company didn’t survive, but the technology was really cool - it let you allocate CPU/memory/disk IO channel/network resources per user, allowing for guaranteed resources for each user’s processes. It was intended for multitennant hosting, and the company was a spinoff of a large hosting provider).
Here’s the configuration from VMware Workstation:
(The cores is not changeable in this VM because the VM I used for the screenshot is actively running - VMware allows some hardware configuration parameters to be changed while running, but not all of them)
Are you sure? All specs I can find say 18 cores/36 threads.
Oh, yeah, you are correct. I was just going off what /proc/cpuinfo
reports, and each thread is reported as a CPU.
My mistake.
Here’s the available cpu settings in libvirt cpu configuration. The 36 number is only my perturbation and 6 is the actual number used.
I have been running phoronix memory tests on my host at various cpu governor settings as set by cpupower. I’m doing this to see what potential speedup might be possible in the gentoo vm.
This might be achieved if the speedup in the host gets through to the vm and might represent the max possible attainable speedup. phoronix runs about 30 tests of memory in this test series. The results from the tests with cpu at “performance” governor settings were improved over those with governor set at “powersaving” setting. But the differences varied greatly between the different tests so that an overall percent speedup determination is very difficult to determine. It would also, likely be controlled by the mix of processes running in the gentoo emerge process. In general 20% might be max expected number.
On a 19 hr process, this does represent 4 hours or so. Significant enough so that I will put openSUSE host into performance mode. Additionally I will give it more cpus.
I do need to settle on sockets, cores, and threads settings; perhaps by experiment.
thanks all, tom kosvic
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.