This is the mail archive of the cygwin 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: /proc/cpuinfo vs. processor groups

Corinna Vinschen writes:
>> I'm a bit puzzled about the connection between MaximumProcessorCount
>> and ActiveProcessorCount here.  Why isn't MaximumProcessorCount 16
>> as well?  Setting it to 64 doesn't make any sense for a system with
>> 32 logical CPUs in total.

The way I understand it is that this is basically a lie by the BIOS to
get the desired effect of Windows creating two processor groups that
neatly separate along the NUMA boundary (which is are the two sockets in
this case).  With newer Windows versions (or certain patches applied to
the older ones) that would not be necessary (and would probably create
processor groups where the active processors and the maximum number of
processors are the same).  I still don't know if it's possible to create
shifted or discontinous processor maps, but it seems there'd be quite a
few programs that stopped working if that happened, so it can't be

>> I'm not sure just simply using ActiveProcessorCount rather than
>> MaximumProcessorCount is the right thing to do...
> Nevertheless I pushed a patch doing just that, plus...
>> > > As an aside, the cache size is reported as 256kiB (not just for this
>> > > processor, but also for a Celeron 1037U on another machine), which seems
>> > > to be the L2 cache for a single hardware core on these architectures.
>> > > Linux now reports L3 cache sizes (and possibly L4 if present) for these
>> > > (20MiB and 2MiB per socket respectively).
>> L3 is easy.  Checking the Linux kernel source I don't see that it
>> reports L4.
> ...L3 reporting for Intel CPUs.  I'm just building a new developer
> snapshot I'll upload to shortly.  Please
> give it a try.

Just as I had my own patch ready... :-) not only did I get a more beefy
CPU than requested, I also got a large enough data disk configured this
time, so I can compile Cygwin again from source.  I can confirm this
works as expected now.  I think the flags indicating presence of the new
barrier instructions are still missing.  It would also be nice if the
microcode patch level could be exposed, but I don't even know if it's
accessible on Windows from userspace.

There are oher applications that still don't work (at all or correctly)
when more than a single processor group is present, so I'll have our
hardware admins change the BIOS settings to "flat" mode in about a week
or so.  I might be able to play a bit with the boot options to create
processor groups in the Windows kernel if I'm allowed to change these
myself (haven't asked yet), but if you need more info from the system in
the current configuration please let me know.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:

Problem reports:
Unsubscribe info:

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