Hi Christian,

On 3/8/2025 9:11 AM, Christian Franke via Cygwin wrote:
Testcase:

$ grep processor /proc/cpuinfo | tail -1 # i7-14700K
processor       : 27

$ sleep 60 & taskset 0x1 sleep 60 &
[1] 62094
[2] 62095

$ taskset -p 62094
pid 62094's current affinity mask: fffffff

$ taskset -p 62095
pid 62095's current affinity mask: fffffff

This may well be the first test of Cygwin's affinity support on a system where the cpu mask bit length isn't a power of 2. I did test such but seeing it on hardware is another matter.

Are there in fact just 28 hardware processors on this system? Does Windows (or Linux for that matter) allow one to set cpu group size? I would think the BIOS would want control over that, with the OSs just providing read access to what was chosen. For 28 processors, a single group of 28 processors, or either 4 groups of 7 procs, or 7x4, or even 2x14 or 14x2 are plausible if not all useful.

Another test shows that the affinity mask is correctly set to 0x1 by sched_setaffinity().

That's good to hear.

In sched.cc:__sched_getaffinity_sys(), GetProcessAffinityMask() is called, but its 'procmask' result is never used. The returned cpu_set is build using groupmask(__get_cpus_per_group ()) which is constant, here 0xfffffff. The original commit 641ecb07 likely worked (until 687c4bad^) on older Windows versions which did not support cpu groups.

Oops on the unused result. I think the intent was to fold it into the process group info to return combined mask values (somehow).

I don't know how to fix this for systems with more than one cpu group, so no patch provided.

The notion I had during implementation was that we're emulating the Linux view of affinities if that differs from Windows. The existing code is intended to take multiple cpu groups into account because the complete cpu mask for the system is being considered and/or returned.

I will re-read the MSDN docs for Windows' affinity functions. They may well have been updated since I last read them.

It might be needed to handle interesting corner cases: "If the process had explicitly set the affinity of one or more of its threads outside of the process' primary group, the function returns zero for both affinity masks." https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase- getprocessaffinitymask

Yeesh, those cases are the kind of gotchas we want to find because Windows may well differ from Linux in how they're handled.
Thanks,

..mark


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to