X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=DMlPxDU2kebVD25x2cv1/yDoJ9GVgFZM1KwaJlXBqica9g6rVpJ5O
	qB1oAX1YEa1jARASvUB4KjfB3ZjZcv4+zyr9EomFlA2vDwSVavMnFFfaeZYq1MUu
	HOm5NJPcPhyiEsZJUqr4DUYq+BJjqc/p3+0tU684R7PKnh04d07wBI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=QDlz5EeDXXfh+2BbvBST0vepYUg=; b=VIoFeo3habkTYCSCk10J87ecObId
	56z5bopXGJ6l9bPYIUZePNNoyN5j8dsdhYVSJcK+6BAog9qD73/LG2b0is0GSVaf
	+n1U5g4QGld7n1sWrXf55e/REqQtZof5s5igllFfThsTED2bRWw2uRpSUiS+gkVB
	f5MPqXjmAJp4DA8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-106.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=
X-HELO: mout.kundenserver.de
Date: Wed, 11 Apr 2018 11:28:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: /proc/cpuinfo vs. processor groups
Message-ID: <20180411092841.GL29703@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <878t9vt3vs DOT fsf AT Rainer DOT invalid> <20180411070241 DOT GJ29703 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Dx9iWuMxHO1cCoFc"
Content-Disposition: inline
In-Reply-To: <20180411070241.GJ29703@calimero.vinschen.de>
User-Agent: Mutt/1.9.2 (2017-12-15)
X-UI-Out-Filterresults: notjunk:1;V01:K0:eYIu9r61h8s=:ipd+shQRhyMrm3SFe5WUhI NCvoahGG9m9mE2rMkNhGTo0DI6Fco1EvHsv3/digUn9OmSdCQehI5vFS90p3+kH64mMmJM/CK o7xdEglcXKm5QqglClHcpVN0oPO58PMl/sA7DNt+uQybH5+xUllSL+piTdT5++Bq0CDDgFCdx x0f+EIarz6ZSgM8tOJJBKC/EIXMr2fu2/K28KIC5YptQqcTFsW9g3OWGOpfNLQY+U4gnEf9Qx 7PdPNc++1Y0s2shGrQhTuiZSNrQfy2C3c89NyhzZqUUgAlsy1v0qYV2t40mk8CmZYBlh8Tp6U stUyH9dsHsWBMhAcvZxW5HINOkhV9pCgbSc/m7ZyncDfK/xZTYci724g0mdUtrpFCtSFNRKtx UTsKCkZc2/eOJNGPdXaJ24uNpZ47dFx1Uzqpjh2QwOU7q646buNiS5KOUH4p8b2wdk1ctHpsz 99qWw7gdtjh1oUlc68/4kp+AB55o1dYwY2Xrk2fqrB/ETj5HFrMLM0oFgc9W4A+z+GQt45VPV BftqTGluXOql6sSnXf9fZHpkfQ6HfhTxPzk+grAEPC/nvYNlGgP1hxfLo8UMCSL1vgghX76q4 55kD5Po1dav5kar+3nadCTyRjti3bNbeCqw3eqnwAHMKWjZoU9VpuhDrjfX4ijAJ3iNJEVs5o BtLffcT0wlmvHIbz0anLCKYKW3hsZZQT2W3lEeh9T8aWfBVJ2uJeLoSOG//mOn4HN9guBMRaR FfE2nriOUSvMITqiyaxynqvU1/BPvO2V8MT9/g==

--Dx9iWuMxHO1cCoFc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 11 09:02, Corinna Vinschen wrote:
> THanks for the report but this belongs to the cygwin ML.
> I'm redirecting this here.
>=20
>=20
> Corinna
>=20
> On Apr 10 18:36, Achim Gratz wrote:
> >=20
> > As briefly discussed on IRC I've got a new Server 2016 blade with 2
> > sockets =C3=97 8 cores =C3=97 2 HT =3D32 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).
> >=20
> > --8<---------------cut here---------------start------------->8---
> > 64bit (166)~ > cat /proc/cpuinfo
> >       0 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(10=
000,0 (10/16)) failed Win32 error 87
> > [...]
> > This results in Windows coming up with two 64 core processor groups that
> > have 16 active logical processors each:
> >=20
> > --8<---------------cut here---------------start------------->8---
> > (gdb) print plpi
> > $1 =3D (PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX) 0x600008020
> > (gdb) print *plpi
> > $2 =3D {Relationship =3D RelationGroup, Size =3D 128, {Processor =3D {F=
lags =3D 2 '\002', Reserved =3D "\000\002", '\000' <repeats 18 times>, Grou=
pCount =3D 0,
> >       GroupMask =3D {{Mask =3D 4160, Group =3D 0, Reserved =3D {0, 0, 0=
}}}}, NumaNode =3D {NodeNumber =3D 131074, Reserved =3D '\000' <repeats 19 =
times>,
> >       GroupMask =3D {Mask =3D 4160, Group =3D 0, Reserved =3D {0, 0, 0}=
}}, Cache =3D {Level =3D 2 '\002', Associativity =3D 0 '\000', LineSize =3D=
 2, CacheSize =3D 0,
> >       Type =3D CacheUnified, Reserved =3D '\000' <repeats 12 times>, "@=
\020\000\000\000\000\000", GroupMask =3D {Mask =3D 0, Group =3D 0, Reserved=
 =3D {0, 0,
> >           0}}}, Group =3D {MaximumGroupCount =3D 2, ActiveGroupCount =
=3D 2, Reserved =3D '\000' <repeats 19 times>, GroupInfo =3D {{
> >           MaximumProcessorCount =3D 64 '@', ActiveProcessorCount =3D 16=
 '\020', Reserved =3D '\000' <repeats 37 times>, ActiveProcessorMask =3D 65=
535}}}}}
> > --8<---------------cut here---------------end--------------->8---
> >=20
> > I've confirmed that the error message is not printed if I manually
> > correct the information for processor ID 17 as follows:
> > [...]

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

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


Corinna

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

--Dx9iWuMxHO1cCoFc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlrN1UgACgkQ9TYGna5E
T6ArQg//VooWh/C2R51JYkXBE8u2OcU+d9KyhPu4EGOUzFZRqsr/2yQqxLtEJhZS
uUergy6GOSRKT0+X7bvunxFTAyEVQFzqEkCeihY/6e4wdvTswz+LEyVh1gVPgy+c
Qm2y3xh2erjk9ztjAJmGdO739S8mte8z5uRpjw84JaguZAHCrrlghMDmH0U4rSEO
YNNkUYI8OaY8/9gFnYWKbQ3S67rVRgqvAaOELVCrwbcYLwMLn4rxb9Hm+74g2hoI
gWZ/ClsQBamJzRFjH+ytjfyokMLInchZiaa1sueCUy53mWpEQVZlwSycS98krqcb
E/hU5wzoo0Vcvb+cjNiztsqs5qSy+KUd9Vojw25Xuf8zp6OBKe9MaNwGNMarxnQL
IaG4i0b2x1D9sK+3k4UAb895uBkeqqGNW4EIOQFSkDPDKiy1s5crU1QkzIdf+xkO
tApA5IwdzGOmdFF0axATAt/aUX1YsUjL7mNMyp0GGEksfW4o4VZfBpA7RYhE8zDE
csZRikVRXrPUiJsKGZRuijAvEWlyHI2WsSykTqCvwBX0U9Oge66vAppChok/t1rp
giuRaN+Qzgmmi39XvP12WxnzggvMXOtk+9PFTqMrZ8UiVjQZ0JQsvuyxngkFGikG
3tAddKzbK+fIQGm42loL6SU9y1VdJmaHvr3wcnwxbls+VnpwxNc=
=fhBp
-----END PGP SIGNATURE-----

--Dx9iWuMxHO1cCoFc--