Implement sched_[gs]etaffinity()
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Apr 16 10:45:00 GMT 2019
On Apr 16 01:19, Mark Geisert wrote:
> On Fri, 12 Apr 2019, Corinna Vinschen wrote:
> > Yeah, right, I missed to notice that. I'll add a few notes inline
> > over @ cygwin-patches.
>
> I've updated my code locally to account for your notes on cygwin-patches;
> thanks! I've also spent some time researching Windows affinities vs Linux
> affinities and have come to some conclusions. I'm airing these for review
> before I start coding in earnest. I appreciate all comments from anybody
> interested.
>
> (1) On Linux, one deals with processor affinities using a huge mask that
> allows to choose from all processors on the system. On Windows, one deals
> with processor affinities for only the current processor group, max 64
> processors in a group. This implies conversion between the two "views" when
> getting or setting processor affinities on Cygwin.
>
> (2) On Linux, sched_get/setaffinity() take a pid_t argument, but it can be
> either a process id or a thread id. If one selects a process id, the action
> affects just the main thread of that process. On Windows, selecting the
> process id affects all threads of that process.
>
> (3) For completeness, Linux's pthread_get/setaffinity_np() should probably
> be supplied by the proposed code too.
>
> (4) I was looking at Cygwin's fhandler_proc.cc, function
> format_proc_cpuinfo(). There's a call to __get_cpus_per_group() which is
> implemented in miscfuncs.cc. I haven't seen in the MSDN docs whether each
> processor group is guaranteed to have the same number of processors. I
> might even expect variations on a NUMA system. Anybody know if one can
> depend on the group membership of the first processor group to apply to all
> groups?
Maybe https://go.microsoft.com/fwlink/p/?linkid=147914 helps?
"If the number of logical processors exceeds the maximum group size,
Windows creates multiple groups by splitting the node into n groups,
where the first n-1 groups have capacities that are equal to the group
size."
We were over that already when creating the code in format_proc_cpuinfo.
So, IIUC, , and IIRC, the idea is that the logical CPUs are split into
equal chunks of logical CPUs, along NUMA node bordres on a NUMA system,
and the last group has potentially, but seldomly, less nodes.
in the end, the important thing is that all groups have equal size,
except the last one.
Therefore:
WORD cpu_group = cpu_number / num_cpu_per_group;
KAFFINITY cpu_mask = 1L << (cpu_number % num_cpu_per_group);
That also means the transposition between the groupless linux system
and the WIndows system is fairly easy.
> (5) On Windows, a process starts out in a particular processor group. One
> can then change thread affinities in such a way that some threads run in a
> different processor group than other threads of the same process. The
> process becomes a "multi-group" process. This has implications for the
> conversions discussed in (1).
Don't see how. Care to explain?
> (6) On Linux, processor affinity is inherited across fork() and execve().
> I'll need to ensure Cygwin's implementation of those calls handle affinity
> the same way.
Just passing the INHERIT_PARENT_AFFINITY flag to CreateProcess{AsUser}
should do the trick.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20190416/156170b5/attachment.sig>
More information about the Cygwin-developers
mailing list