Web lists-archives.com

Re: /proc/cpuinfo vs. processor groups




On Apr 11 11:28, Corinna Vinschen wrote:
> On Apr 11 09:02, Corinna Vinschen wrote:
> > On Apr 10 18:36, Achim Gratz wrote:
> > > As briefly discussed on IRC I've got a new Server 2016 blade with 2
> > > sockets × 8 cores × 2 HT =32 logical processors and Cygwin spews errors
> > > for processor ID 16 and up (also top doesn't quite work, which likely
> > > has the same reason, although the code path may be unrelated to the
> > > /proc/cpuinfo bug described here).
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > 64bit (166)~ > cat /proc/cpuinfo
> > >       0 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(10000,0 (10/16)) failed Win32 error 87
> > > [...]
> 
> 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.
> 
> 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 https://cygwin.com/snapshots/ shortly.  Please
give it a try.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature