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 Apr 16 21:31, Mark Geisert wrote:
> On Tue, 16 Apr 2019, Corinna Vinschen wrote:
> > On Apr 16 01:19, Mark Geisert wrote:
> > >   Anybody know if one can
> > > depend on the group membership of the first processor group to apply to all
> > > groups?
> > 
> > Maybe 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."
> Great; thanks for that.
> > [...]
> > 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.
> Yes, dealing with an array of unsigned longs vs bitblt ops FTW.
> > > (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.
> OK.  Hope so.

Well, nope, sorry.  Per MSDN:

  The process inherits its parent's affinity. If the parent process has
  threads in more than one processor group, the new process inherits the
  group-relative affinity of an arbitrary group in use by the parent.

  Also important: This value is not supported on Vista, so it should
  only be used if wincap.has_processor_groups() is true.

> (7), to make a prime number: I don't see any need for the Cygwin DLL to keep
> any affinity info (process or thread) or processor group membership info
> around, do you?  I believe the sched_get/setaffinity functions will do
> whatever Windows ops they need to do on the fly based on the args passed in.
> That allows the user to do Windows affinity ops at will outside of Cygwin
> without screwing up any Cygwin-maintained context.

I agree.  Additionally I think we should not overvalue affinity
inheritance.  Specifying INHERIT_PARENT_AFFINITY should be enough
for a start.  There's no reason for overkill.


Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature

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