This is the mail archive of the cygwin-patches 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: [PATCH v2] Cygwin: Implement sched_[gs]etaffinity()

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?


> 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.

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


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]