Mark Geisert wrote:
Due to deficient testing, the current code doesn't return a valid result
to users of sched_getaffinity(). Carry the result procmask through to
the generation of result cpu mask.
Recognize Windows' limitation that if the process is multi-group (i.e.,
has threads in multiple cpu groups) there is no visibility to which
processors in other groups are being used. One could remedy this by
looping through all the process' threads, but that could be expensive
so is left for future contemplation.
Reported-by: Christian Franke <christian.fra...@t-online.de>
Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257616.html
Signed-off-by: Mark Geisert <m...@maxrnd.com>
Fixes: 641ecb07533e ("Cygwin: Implement sched_[gs]etaffinity()")
Could only test the single cpu group (aka single physical cpu) case
which is the most common, I guess. Works as expected:
$ uname -r
3.6.0-dev-440-g5ec497dc80bc-dirty.x86_64
$ grep '^model name' /proc/cpuinfo | uniq -c
28 model name : Intel(R) Core(TM) i7-14700K
$ stress-ng --pthread 1 -v &
[1] 1323
...
stress-ng: debug: [1324] pthread: [1324] started (instance 0 on CPU 10)
$ taskset -c -p 1324
pid 1324's current affinity list: 0-27
$ taskset -p fff0000 1324 # All E-cores
pid 1324's current affinity mask: fffffff
pid 1324's new affinity mask: fff0000
$ taskset -p fff5555 1324 # All cores but no HT
pid 1324's current affinity mask: fff0000
pid 1324's new affinity mask: fff5555
$ taskset -c -p 8,9 1324 # P-core 4 with HT
pid 1324's current affinity list: 0,2,4,6,8,10,12,14,16-27
pid 1324's new affinity list: 8,9
$ taskset -p 1324
pid 1324's current affinity mask: 300
The settings have the desired effect on reported core usage.
--
Thanks,
Christian
