[PATCH v2] Cygwin: Implement sched_[gs]etaffinity()
Mon Apr 29 09:42:00 GMT 2019
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
> 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.
> > > + // 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.
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin-patches