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