Workstation 16pro on alder lake system

[senwebtek]

Is there any information on using vmware workstation with alder lake systems? How would processor allocation between P and E cores work or is it handled automatically by the processor? I'm getting ready to build a new system and I'm trying to decide whether to go with an i7 12700k alder lake or a ryzen 5900x. Any input would be appreciated.

[harleylg]

It seems vms only using e-cores with p-cores idle……

Here's a screenshot, my vm compiling gcc with 17 thread, and the vm is 16 cores, only e-cores are working

 

[SeanLiuLiu]

I have met this problem too.  I have checked the Virtual Box doesn't have the same cpu schedule issue.

It's not the linux's fault. It's not the windows 11 fault.

I still feel Workstation Pro better on my work.

Vmware developers can fix it? When? Who can help us???

So sad

[bluefirestorm]

You could try setting processor affinity in the vmx configuration file. But this should be treated as a workaround as it is not so efficient and not optimal to be setting CPU affinity to VMs.

Using harleylg's screenshot and sample 16 vCPU VM configuration, assuming the last 8 logical CPUs are the efficiency cores, adding the following means the last 8 logical CPUs (16-23) won't be used and only Processor 0 to 15 (assuming these are the performance cores with hyperthreading) will be used by the VM.

Processor0 = "TRUE"
Processor1 = "TRUE"
Processor2 = "TRUE"
Processor3 = "TRUE"
Processor4 = "TRUE"
Processor5 = "TRUE"
Processor6 = "TRUE"
Processor7 = "TRUE"
Processor8 = "TRUE"
Processor9 = "TRUE"
Processor10 = "TRUE"
Processor11 = "TRUE"
Processor12 = "TRUE"
Processor13 = "TRUE"
Processor14 = "TRUE"
Processor15 = "TRUE"
Processor16 = "FALSE"
Processor17 = "FALSE"
Processor18 = "FALSE"
Processor19 = "FALSE"
Processor20 = "FALSE"
Processor21 = "FALSE"
Processor22 = "FALSE"
Processor23 = "FALSE"

 

[harleylg]

It works. But the correct .vmx config should use 

Processor1.use = "TRUE"
Processor2.use = "TRUE"
Processor3.use = "TRUE"
Processor0.use = "TRUE"
Processor4.use = "TRUE"
Processor5.use = "TRUE"
Processor6.use = "TRUE"
Processor7.use = "TRUE"
Processor8.use = "TRUE"
Processor9.use = "TRUE"
Processor10.use = "TRUE"
Processor11.use = "TRUE"
Processor12.use = "TRUE"
Processor13.use = "TRUE"
Processor14.use = "TRUE"
Processor15.use = "TRUE"
Processor16.use = "FALSE"
Processor17.use = "FALSE"
Processor18.use = "FALSE"
Processor19.use = "FALSE"
Processor20.use = "FALSE"
Processor21.use = "FALSE"
Processor22.use = "FALSE"
Processor23.use = "FALSE"

 

[bluefirestorm]

I wrote a short Python script for that and forgot to put the .use before copy/pasting the output

Sorry about that.

I paste here the corrected code in Python

for i in range(24):
    processor = f'Processor{i}.use = "{"FALSE" if i > 15 else "TRUE"}"'
    print(processor)

Here is a bash version

#!/bin/bash

for n in {0..23}
do
if [ $n -le 15 ]
then
printf "Processor%d.use=\"TRUE\"\n" $n
else
printf "Processor%d.use=\"FALSE\"\n" $n
fi
continue
done

[SeanLiuLiu]

I had done two tests. The results are obvious that adding above settings did works. But all TRUE can't be reaching our goal.

How can we using p-cores and e-cores at the same time? Guys, do you have any better ideas?

[Ricebucket]

I tested this out. It seems that even if 1 efficiency core is enabled, it will not use any power cores. This means that at most I can use only 16 cores out of the system. This sucks.

[TimothyHuckabay]

I have sent this to VMware's technical support:

Regarding Intel's twelfth generation (Alder Lake) and later CPUs, they have a mixture of P (Performance) and E (Efficiency) cores.  Here's the problem: Workstation 16.x and earlier does NOT recognize the distinction between those two types of cores, confuses them, and FAILS TO WORK with both types simultaneously; in other words, to boot a Workstation VM on a a host system with such a physical CPU, it is necessary to use ONLY ONE CORE in the VM—OR TO DISABLE ALL THE EFFICIENCY OR ALL THE PERFORMANCE CORES via the configuration file beforehand.  Either "workaround" results in a hobbled system, in which Workstation VMs are only able to utilize a limited number of available physical cores.  That necessarily gives AMD CPUs an advantage going forward, until VMware fixes the problem with Workstation.  So, Workstation 17.x and later needs to be fixed in terms of virtual CPU hardware, to be able to simultaneously use both P and E cores in Intel's twelvth and later generation x86 processors.

[mark-reijerkerk]

You are the man.

My VM which is running W11 Pro with the TPM patch I finally have a good response.

[SeanLiuLiu]

Hi, guys! I'm completely sure I found a way, which can handle the issue. We can make the most of all physical cpus for Intel 12th-gen alder-lake architecture.
The following is my checked results. Please set these configurations strictly according to the first two pictures. Let's check these out!
Hope this way could help anyone who meets the same problem just like me.
Note: Seeing the more details is at https://www.bilibili.com/video/BV1G44y1g7RT?spm_id_from=333.337.search-card.all.click

[ipxu]

Hi Guys, 

I'm planning for upgrading to i9 12th gen and wondering if this issue still on and VMware still did not solve it!

 

 

[harleylg]

Until today, it still exists

[neet2user]

FYI (´・ω・`)つ　https://www.windowscentral.com/assign-specific-processor-cores-apps-windows-10

Winows Powershell startcommand.

RHEL8 latest version nice command.

[gbackulmer]

:Thanks for sharing your fix! Is it possible for you to translate the preferences/options in english? I'm sorry, not able to understand the chinese(?) font/signs... Would be great!

GB

[harleylg]

Just set Windows Power mode to "Best performance" will be ok

[prefname]

Is any of this confirmed/acknowledged/Kbed by vmware? Alder lake has been out for quite a while now, how is it possible they don't have anything to say about it?

 

I'm trying to decide between win10 and win11 host. Would prefer win10, unless win11 is less broken with respect to this.

 

Is my understanding from this thread correct that by default, vms on a win10 (21H2) host it will only use e-cores? Does this depend on the number of cores allocated to the vm?  And the only workaround is to specify affinity to only p-cores (ProcessorN.use).

 

Is it the same on win11?

 

To me the ideal would seem to be the ability to allocate p and e cores separately to VMs via the workstation UI. Then the guest OS that supports this, would know that it has X p-cores and Y e-cores and would use its own scheduling.

 

What is the alternative? If the guest is core-blind, will the host have enough info to decide where to run a guest thread?

[robertspelman]

My Win11 host and Win10 guest had this issue until I manually assigned the processor core affinity in the VMX file. Now it is using 8 cores at 100% inside the guest, which is being spread between 12 cores on the host. As I'm only expecting to run this one VM that's not a problem for me.

[gworboys]

First, thanks for this thread, it helped me work out what was going on.

There is a second work-around: start Workstation as administrator.

Alternatively, a slightly simpler implementation of the previous advice seems to be that you can simply tell the .vmx which processors to exclude (all the others get included anyway).  So adding just these four lines worked for my i7 12700:

processor16.use= "FALSE"
processor17.use= "FALSE"
processor18.use= "FALSE"
processor19.use= "FALSE"

 

Some extra notes:

I'm using Workstation v17.0 but the notes above seem to suggest it happens on older systems too.  Host running Windows 11 22H2, mostly experimenting with Win10 guests.

I have two new almost identical systems running i7 12700 Alder Lake systems.  8 p-cores, 4 e-cores, all up 20 logical CPUs, so the e-cores are CPUs 16, 17, 18 and 19.

The only difference between the two is that one runs Workstation via Run As Administrator so that one of its VMs can access some physical drives directly.  That system has been running normally for a few days, and explicit tests appear to show that it never runs on CPUs 16..19 (or not enough to show).

The other system changes around a lot.  At first all seemed normal, but I'd come from older hardware so the CPU allocations were all 4 or less, and these seemed to work okay most of the time, or not obviously horrible.  But as soon as I tried 6 or more CPUs even just the start up time of the VM blew out to minutes and you could see top four CPUs going mad:

Presumably this related to the explanations above about Wkstn being locked into the e-cores and having trouble trying to switch the 6 CPU VM over just 4 CPUs.

As noted at the top, I can get rid of the problem by excluding those four CPUs, or by running Workstation as admin.

I thought I'd post this extra detail in case it helps others facing the problem - and perhaps explains why some others don't see it.

[mtomei]

Just tell Windows to not "optimize" the application. With that setting the process will never be moved on e-cores when backgrounded.
Tested with W11 22H2

powercfg /powerthrottling disable /path "C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe"

 

[gworboys]

Excellent, thanks for that, it's a much better option.  Plus it's dynamic, you can change the /powerthrottling setting on the fly and it picks up straight away (so "reset" to go back to original setting, "disable" to turn off throttling, "list" to show what is configured).

It appears to be a per-user setting - so the list for administrator is different to my normal user list.

The other thing I noticed is that you can show "Power Throttling" in the Task Manager "Details" tab, but it never showed vmware-vmx.exe being throttled, regardless of this setting, and yet you could see the change in CPU load almost instantly on Process Explorer. (I never expected it to be throttled, this is a desktop system - no battery - and historically Windows didn't do throttling on desktops, not sure if/when that changed.  I wonder if having a UPS plugged in - which I do - makes any difference to what Windows decides to do in this regard?)

[WinniVM]

This is a really nice solution. Thanks a lot!

It is also working for the vmware player: 

powercfg /powerthrottling disable /path "C:\Program Files (x86)\VMware\VMware Player\x64\vmware-vmx.exe"

[JamesDeanReally]

This is a great solution. Thank you.

[ig-andrew-edney]

I tried that and it didn't seem to make a lot of difference, do you need to reboot the host for it to take effect?

When I checked in Task Manager it was clear the process had power throttling disabled, but it was still being run using the e-cores.

A solution which worked for me, but may need to be applied each time I start a VM (yet to be sure) was to run Task Manager as administrator and use the processor affinity option to say it can run only on the p-cores.

[ig-andrew-edney]

Hmm, the processor affinity may work but it's not ideal as it seems to need setting each time.

[gworboys]

It's a shame that the powercfg option is not working for you.  It continues to work for me: VMware Workstation v17.0.0, and Windows 11 22H2.

I have found that some Windows updates appear to clear the list of disabled programs which requires that you re-issue the command, so I've set up a shortcut to simplify that.  But my experience is that running the powercfg command described gives almost instant results - not only do you not have to reboot the host, you don't even have to restart the VM.

If that doesn't work for you, have you tried running Workstation as administrator?   I have two almost identical systems here and one does not need the powercfg command because it always runs Wkstn as administrator.   I don't know why that works, but it seems to be reliable (same config as described above).

[jcollake]

You can use Process Lasso to persist the CPU affinity, so it doesn't need set every time.

[prefname]

Here's what I found with the "powercfg /powerthrottling disable" approach. Whereas it does enable the use of p-cores, it does not seem to prevent e-cores from sneaking in, even when p-cores should be available (i.e. they're not too busy). I've experienced intermittent significant slowdowns of certain long running cpu-bound operations in a vm, that went away when I went back to forcing p-cores with processorX.use. Somehow a vm process (vmware host thread) would appear to get stuck on an e-core.

 

Despite Intel's and Microsoft's hand-waving about their AI scheduling, it can't be perfect. So both windows and vmware should provide good UI for manually overriding the scheduling policy, but neither do.

 

Does windows have any config that persistently disables or at least heavily de-prioritizes e-cores for an app? The ephemeral setting of cpu affinity of a running process instance does not qualify.

 

Vmware vm config UI should have something like following e/p-core options:

• let os decide
• prefer p-cores
• only p-cores
• prefer e-cores
• only e-cores

[gworboys]

 your previous post (Aug 2022) indicated you were running a Windows 10 host, is that still the case?   Are you running Wkstn 16 or 17?   (Just so we some comparison can be made with others experiencing the problem.)   Similarly, it can be helpful know what sort of long running running is causing you trouble, so others can try it and see what happens in their system.  (Compiling seems unlikely to be it, as that is normally a mass of small tasks, so perhaps video encoding.)   The other thing that would be interesting to know is how many CPUs you are allocating to the VM(s) and how many VMs you are running when you get into trouble.

As I have already noted, on my Win11 22H2 host running mostly Win10 and now Win11 guests, I have two ways to avoid the e-core issue.

* the powercfg command as previously described

* running VMware Workstation as administrator

I have two identical systems, one running each solution and so far both work reliably for me, except that powercfg has dropped out a few times due to Windows Updates (that seem to have cleared the settings and so require the command to be issued again).   But with this i7-12700 I rarely end up using more CPUs in my VMs than I have on the host, so maybe I just haven't been pushing hard enough to see the trouble you see.

It would be interesting to hear if running as administrator works for you.

[prefname]

win11 22H2 host, workstation 16.2.5, ubuntu 20.04 guest, 6 cores for the vm

vm was doing a kind of compilation with a long running process handling multiple files

Since the intermittent slowdowns stopped when I went back to processorX.use, I don't plan on doing further experimentation.

 

[gworboys]

Thanks for the extra info.  And certainly I understand about not planning further experimentation now you have things working well enough ... until you upgrade to Wkstn v17 it would probably not achieve a lot anyway, since we have no way of knowing what might have been fixed in this regard between the two versions.

It is interesting to see this was a 6 core VM.  When I was seeing the problem here it seemed to be the > 4 core VM that got hit most.  I've been presuming that this has to do with my CPU having only 4 e-cores, which is where the VM was being executed.

[brunofernandez1]

 

thx! that worked for me with VMWare 17 Pro an Win11 (Host and Guest)

[mtomei]

I am currently testing another way using Process Lasso which recently added support for Efficiency mode https://bitsum.com/product-update/process-lasso-12-3-efficiency-mode/
You can create a rule for vmware-vmx.exe or a generic one for all user processes with syntax *:your_username and it seems to work like powercg.

[TanquenETG]

I have the i7-12700H also. I think it's only 6 P-cores and 8 E-cores with another 6 only being hyper threads. I guess only the P-Cores have hyper threads. So only 6 of the fastest real cores for the VM. How do you know which of the 20 are the E-Cores and which are the Hyper threads?

 

[ig-andrew-edney]

Assuming your cores are numbered 0 to 19, the P cores (with HyperThreading) should be 0 to 11, the E cores 12 to 19.

[Michael Minter]

If you want to know for sure which cores have (HyperThreading) use the Coreinfo app (on Windows).

Coreinfo - Sysinternals | Microsoft Learn

My newer Dell has 

Intel(R) Core(TM) i7-14700
Intel64 Family 6 Model 183 Stepping 1, GenuineIntel

....

Processor signature: 000B0671

Logical to Physical Processor Map:
**--------------------------  Physical Processor 0 (Hyperthreaded)
--**------------------------  Physical Processor 1 (Hyperthreaded)
----**----------------------  Physical Processor 2 (Hyperthreaded)
------**--------------------  Physical Processor 3 (Hyperthreaded)
--------**------------------  Physical Processor 4 (Hyperthreaded)
----------**----------------  Physical Processor 5 (Hyperthreaded)
------------**--------------  Physical Processor 6 (Hyperthreaded)
--------------**------------  Physical Processor 7 (Hyperthreaded)
----------------*-----------  Physical Processor 8
-----------------*----------  Physical Processor 9
------------------*---------  Physical Processor 10
-------------------*--------  Physical Processor 11
--------------------*-------  Physical Processor 12
---------------------*------  Physical Processor 13
----------------------*-----  Physical Processor 14
-----------------------*----  Physical Processor 15
------------------------*---  Physical Processor 16
-------------------------*--  Physical Processor 17
--------------------------*-  Physical Processor 18
---------------------------*  Physical Processor 19