https://bugs.winehq.org/show_bug.cgi?id=47068
--- Comment #1 from Roman Stingler coolx67@gmx.at --- Thanks Bob for stepping by
I have further information and thoughts.
http://download.microsoft.com/download/a/d/f/adf1347d-08dc-41a4-9084-623b119...
What I found in the docs
"Support for systems that have more than 64 logical processors is based on the concept of a processor group, which is a static set of up to 64 logical processors that is treated as a single scheduling entity. Processor groups are numbered starting with 0. Systems with fewer than 64 logical processors always have a single group, Group 0."
In the ntdll code there is the comment
" * - ULONG_PTR masks as used in data structures can't hold all cores. Requires splitting * data appropriately into "processor groups". We are hard coding 1. * - Thread affinity code in wineserver and our CPU parsing code here work independently."
I was asking me why there should be hardcoded 1 group? when I run cpuz I figured out that it was showng me 2cpu's, 1 with 64 cores and one with 32cores but it's the benchmark is also using just 64 cores.
so maybe there are more processor groups in the wineserver code, due to the detection of 2 cpu's, but maybe there is the wrong information or missing variables that cpu-z shows a full processor group (64) and one filled with the rest.
Furthermore, in the reading: "The reason for initially limiting all threads to a single group is that 64 processors is more than adequate for the typical application. An application that requires the use of multiple groups so that it can run on more than 64 processors must intentionally determine where to run its threads. The application is responsible for setting thread affinities to the desired groups."
Due to the fact that windows is using more than 64 threads in cinebench or cpu-z benchmark, just to name a few, this tools must be able to assign more than 64 threads to the process (haven't looked if it splits into multiple processes which assigns processor groups).
When I start cpu-z i get
when benchmarking it's following situation https://postimg.cc/k2HwPdBz
tomorrow I will have a look into
GetLogicalProcessorInformationEx()
and maybe if I have time into the wineserver code
In the IRC
Thunderbird told me "I see the discussion now.. blackout, reworking the cpu core reporting is not easy. Others poked me about it too recently (e.g. AMD for Rome) among the issues is we need to deal with "groups" as well and rework all the thread priority code up to wineserver it is quite a big effort, I honestly didn't really want to touch our cpu code.. it is a bit fragile to say the least zf, the thread priority stuff is the biggest part. There won't be a match between the "mask" to pthread_set_affinity and the windows code. Right now if I recall correctly they are the same (by luck)"
So maybe we should plan a refactor of the cpu code.
I would like to plan this and continually add some code or refactor some of it. It would be great if someone more experienced would give me some hints.
By now I have spent maybe 3h with the wine code and some tests and therefore I don't have the big picture where to start or what essential parts are missing.
It would be really nice to see some sort of brainstorming and a plan how to refactor the whole core of cpu code.