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