This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implement sched_[gs]etaffinity()

On Thu, 11 Apr 2019, Corinna Vinschen wrote:
On Apr 11 10:25, Corinna Vinschen wrote:
Hi Mark,

On Apr 10 21:21, Mark Geisert wrote:
I've recently sent a patch to cygwin-patches that implements these
Linux-specific functions.  I used the following test program to debug and
test the implementation.  When the program is run, you can watch it migrate
from CPU to CPU with Windows Task Manager.

I've only tested on 64-bit Windows 7 so far.  If the code (in the patch) is
adequate I will supply another patch for doc updates, etc.

Your patch is nicely done, but what about machines with more than 64
CPUs?  Your patch only uses the standard API for up to 64 CPUs, so a
process can never use more than 64 CPUs or use CPUs from different CPU
groups.  There was also the case of this weird machine Achim Gratz once
worked on, which had less than 64 CPUs but *still* used multiple CPU
groups under Windows, for some reason.

Any chance you could update your patch to support this functionality?
For some info, see MSDN:

Also, there's already some code in, function
format_proc_cpuinfo to handle CPU groups.  You can use the
wincap.has_processor_groups() method to check if the system
supports CPU groups.

Btw., Glibc's cpu_set_t supports up to 1024 CPUs.  See;a=blob;f=posix/bits/cpu-set.h
This may be ok for the foreseable future, I guess.

Hi Corinna,
I will look into CPU group support; thanks for the pointers. I also need to fix the assumption I made about which flavor of pid would be handed to the functions.. they will be Cygwin pids but need conversion to Windows pids internally.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]