Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 23:55:03



Reply to topic  [ 5 posts ] 
CPU Thread Affinity patch for Windows 
Author Message

Joined: 2011-10-07 10:39:20
Posts: 181
Reply with quote
Hi Henri,

i ported the Linux thread affinity code to the equivalent Windows code. It is mostly a simple 1:1 port.

Greetings, Kathrine


Attachments:
affinity.txt [3.12 KiB]
Downloaded 117 times
2022-04-14 20:19:11
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
I already had a look at affinity for Windows. Sadly, it does not work like under Linux. Under Linux, you can set the main thread (process) affinity, e.g. to cores 0 and 1 and child threads affinity to cores 2 to 8. This allows to ensure that child threads won't consume processing time on the cores the main thread (and renderer, for the viewer) is running; this is the whole point of this feature as I implemented it.

Under Windows, however, the child threads of a process can only have their affinity set to a sub-set of the process affinity. E.g. a process could have its affinity set to cores 0 to 8, and child threads only to cores 2 to 8; but as you can see, it won't prevent the main thread to be scheduled on the same cores as the child threads... Or at least, this is how I understand the SetThreadAffinityMask() documentation, and especially:
Quote:
A thread affinity mask is a bit vector in which each bit represents a logical processor that a thread is allowed to run on. A thread affinity mask must be a subset of the process affinity mask for the containing process of a thread. A thread can only run on the processors its process can run on. Therefore, the thread affinity mask cannot specify a 1 bit for a processor when the process affinity mask specifies a 0 bit for that processor.

This means that this feature is not adapted to Windows' scheduler (neither to macOS', that, AFAIK, does not even have any system call to set threads or processes affinity)...


2022-04-14 22:33:34
Profile WWW

Joined: 2011-10-07 10:39:20
Posts: 181
Reply with quote
Not really. Windows just has a slightly different API for affinity.

The Windows API works exactly like the Linux one in that respect. The main difference is how the schedulers distribute the threads when Hyperthreading is active.

You get the Process Affinity Mask, which is "all available cores" by default. So if you do nothing, the threads will be scheduled on all cores of the machine.
This is the same as the default "cpuset" on Linux (https://man7.org/linux/man-pages/man7/cpuset.7.html).
Now you can set the Thread Affinity Mask to control the distribution of threads on the available cores. The main threads affinity mask isn't the same as the process affinity mask.

(see for example: https://stackoverflow.com/questions/248 ... and-openmp )

There are some extra complexities with Processor Groups, NUMA and core topology in multi-socket systems or when more than 64-cores are involved, but for the basic Thread Affinity mask it doesn't matter.

It seems to work properly, when i lookup the best core in Ryzen Master, then set a MainThreadAffinity Mask for the 2 best HT cores. Checking with Process Explorer, the load stays on the selected CPUs as expected and the threads do not migrate away. Could add a few asserts to be sure the main threads stay on the assigned CPUs and to make sure the other threads never go there... (https://docs.microsoft.com/en-us/window ... ornumberex )


2022-04-14 23:45:38
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
kathrine wrote:
The main threads affinity mask isn't the same as the process affinity mask.
Ah... That would indeed be a game changer... The documentation is very confusing for a Linux developer (where a process and the main thread of that process are in actuality the same things: for Linux, each thread is just another (lightweight) process, the secondary threads/lightweight processes simply being parented to the main thread/process), that is you cannot, under Linux, differentiate the "process" from the "main thread"...

Quote:
Could add a few asserts to be sure the main threads
It won't help/be desirable for a release build, but if you can find the time to experience it with an llassert_always(), it would be an interesting confirmation that your interpretation of M$ documentation is the right one. I would be especially worried that the main thread could be scheduled on the child threads reserved cores (largely defeating the purpose of this feature)...

FYI, with the new threaded GL worker (which I also made multi-threaded instead of just mono-threaded), I did more work on affinity setting (I spotted the HttpThread thread affinity, for example, which I so far did not set), so to move more threads away from the main thread/renderer cores; the benefit of the affinity setting should be even more obvious with the upcoming releases. ;)


2022-04-15 08:38:27
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Feature included in today's releases. :)


2022-04-16 11:10:03
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.