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
signature.asc
Description: PGP signature