[PATCH v2] Cygwin: Implement sched_[gs]etaffinity()

[Corinna Vinschen]

On Apr 29 01:54, Mark Geisert wrote:
> Corinna Vinschen wrote:
> > Hi Mark,
> > 
> 
> Howdy!  FTR Here's the intro paragraph left out of my patch submission:
> 
> Second version of CPU affinity patch set.  Attempts to mimic operation
> of Linux affinity functions, both the sched_* and pthread_* varieties.
> This v2 version assumes Windows processor groups always have 64 logical
> processors.  I'm just trying to get the control structures laid out.  A
> later version will deal with smaller-sized processor groups.
> [...]
> > > +#ifdef __CYGWIN__
> > 
> > I don't think we really need that extra ifdef.  #if __GNU_VISIBLE
> > bracketing is sufficient.
> 
> This mod is to newlib but I figured it's not relevant to non-Cygwin
> platforms. Could you please confirm the __CYGWIN__ bracketing can be
> removed?

Confirmed.

> OK on 32 vs 64.  This XXX comment is to remind me to support the smaller
> processor groups before final patch submission.  We have been discussing
> this but I don't think I made it clear I'm considering the "big bitmask" set
> (like Linux uses) and how processor groups subdivide it.  It's an array of
> cpu_set_t (== uint64_t) but when subscripted by group number, it's an array
> of G-bit quantities, where G can be 48 or 36 or ...  Ergo, some bit-aligned
> reads and stores will be needed.

Sure.

> > > +	    // There is no way to assemble the complete process affinity mask
> > > +	    // without querying at least one thread per group in grouparray,
> > > +	    // and we don't know which group a thread is in without querying
> > > +	    // it, so must query all threads.  I'd call that a heroic measure.
> > 
> > I don't understand.  GetProcessAffinityMask() exists.  Am I missing
> > something?  Also, if you don't like GetProcessAffinityMask(), there's an
> > equivalent NT function to NtQueryInformationThread:
> 
> It exists, but if the process you're querying is a multi-group process, the
> mask is returned as all zeroes.  The func only works for single-group
> processes.  I even use it for such a little earlier in this code.

Uh, ok.

> That doc I referenced in my last submission talks about how support for >64
> logical processors was hacked into Windows to allow pre-existing code to
> continue to work.  The down-side of the hackwork is that one has to manually
> place threads into processor groups other than the one selected by Windows
> to run the primary thread.  You can't change the processor group of the
> process.

Yeah, you have to use SetThreadGroupAffinity() to set the process
affinity.  That even *kind of* makes sense, in a twisted way...

But afaiu, the process affinity is not a bitmask but a group mask.  As
soon as a thread gets an affinity mask that adds a group, the entire
group is added to the process affinity.

That would mean calling GetProcessGroupAffinity() is sufficient to get
the process mask.

If you want to be bit-exact, defining the process affinity mask over all
groups as or'ed mask of all thread affinities, you'd have to fetch a
list of all threads of a process and then GetThreadGroupAffinity() for
each of them.  That should work without having to call
SetThreadGroupAffinity().


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-patches/attachments/20190429/5ee3aa0d/attachment.sig>