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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=AhrLHvaBiplXO6abcHMlngXVIONenx+DBBsJG4PuiRcR/1ywTvgs7
	YXPFBYUpZRQeBloXOAblYKqXYSGHHPclM+d0w4WIasS8HgVtS5ivVaReGBXvvakZ
	zzeKSqq62y9bviu6Xsgd60BMTXH4+r/E5W+6W8Tdwn3TZqixNtQcgo=
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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=hobm22TwvknRFRTpCmLc49bSpUk=; b=RNegob+xssuJj1tHRkIgIKq1bGqY
	Myys54B0zp19/8bp88Dfki/rOvzxSpqD1Dlpu4wg6IY6FnWPDPRhlalV8+jyoB7v
	qmGRghvLDMF+LDjxhoI730SeDwLtjPIJmFmcold7yuT9Q4uFAhlRYhLQI468WAFI
	dnBi1hLq9h/9erU=
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.3 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-Spam-User:	qpsmtpd, 2 recipients
X-HELO:	mout.kundenserver.de
Date:	Wed, 11 Apr 2018 09:02:41 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Cc:	cygwin-apps AT cygwin DOT com
Subject:	Re: /proc/cpuinfo vs. processor groups
Message-ID:	<20180411070241.GJ29703@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, cygwin-apps AT cygwin DOT com
References:	<878t9vt3vs DOT fsf AT Rainer DOT invalid>
MIME-Version:	1.0
In-Reply-To:	<878t9vt3vs.fsf@Rainer.invalid>
User-Agent:	Mutt/1.9.2 (2017-12-15)
X-UI-Out-Filterresults:	notjunk:1;V01:K0:mpOA6AgJ1Wc=:xB9UMjoz/8MCjC7AwU+7u8 IrKQCfktNCJIjmOre6ESeTYAq61BYOXu3sHsF/MRJ6loRSI63F06i9cKkw8u9hC4vXvN5c7H0 yL5g/cfOt7dkdVWyhEdy+aGy8+FWjHq0/iW8exJjC+L3TKGZl5agfnAIcUUawPkXOGDQz5X9L GMT51Or3l/FUPGUT37ckoxNJ++A0/F5wCLmZU8xBQxX3QkAPmfY1b4sqoaeveGKEuZruLjANA JAHH95S/3KkWEUYK6Q8pTDb7rJ64tVIwPt/MVc2JBzd9oaVoe/LUC3/gKFw1eUCA3VvbUkBVs 3+Bia29YqQ0XUYNQ/tZxviJlFBcSpN4Lhyg3s0y3Dr4PKfwW2GbhFg+Z/MUylxh4Bh01zjA2U Gvr7x7IoYnAG5mvBWraNkksBGfcZroZxpHVJX7wQi3ySk6SDyc1+MhfOenKWF2MZORJQQWAIY lWzbGj0csUL1LwCCyEojYSIabQ8DBEtJe4LsUrC7LAYDznS/m36wMuznpOXbFC0tqW23eDCnz tDE5WP/R+vAaGsJBk9W9MO5Q8333HHZkAiwJbmH5+Xv6fMtEqIvVGxG2Jtw3YXpjPaeMXiJxv as8FyC4k3rQ8I7kbdpPp2T0yBhZy/hnx5Bz+PaUteNYZ08HeoiHOdeycfSrJJBj0Ypp2MOHxu zoBpl2PgcDkkmDj0oX6ugki+xqZQWHK8f5r21uN8K/i+w4Z+Id70yj9OTm5D1K/dfhNjOaIiR 6ictgZjoA6VbB2AepIyyhdUQMV1hnSi2Y8TknA==

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

THanks for the report but this belongs to the cygwin ML.
I'm redirecting this here.


Corinna

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 sp=
ews 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(1000=
0,0 (10/16)) failed Win32 error 87
>     209 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(2000=
0,0 (11/17)) failed Win32 error 87
>     913 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(4000=
0,0 (12/18)) failed Win32 error 87
>    1047 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(8000=
0,0 (13/19)) failed Win32 error 87
>    1151 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(1000=
00,0 (14/20)) failed Win32 error 87
>    1266 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(2000=
00,0 (15/21)) failed Win32 error 87
>    1383 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(4000=
00,0 (16/22)) failed Win32 error 87
>    1479 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(8000=
00,0 (17/23)) failed Win32 error 87
>    1573 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(1000=
000,0 (18/24)) failed Win32 error 87
>    1675 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(2000=
000,0 (19/25)) failed Win32 error 87
>    1806 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(4000=
000,0 (1A/26)) failed Win32 error 87
>    1888 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(8000=
000,0 (1B/27)) failed Win32 error 87
>    1971 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(1000=
0000,0 (1C/28)) failed Win32 error 87
>    2069 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(2000=
0000,0 (1D/29)) failed Win32 error 87
>    2154 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(4000=
0000,0 (1E/30)) failed Win32 error 87
>    2247 [main] cat 10068 format_proc_cpuinfo: SetThreadGroupAffinity(8000=
0000,0 (1F/31)) failed Win32 error 87
> --8<---------------cut here---------------end--------------->8---
>=20
> It turns out this is related to processor groups and some changes that
> probably weren't even in the making when the Cygwin code was written.
> These changes were opt-in patches until 2008R2, but are now the default
> in 2016:
>=20
> https://blogs.msdn.microsoft.com/saponsqlserver/2011/10/08/uneven-windows=
-processor-groups/
>=20
> The BIOS on that server does something rather peculiar (it does make
> sense in a way, but Cygwin clearly didn't expect it):
>=20
> https://support.hpe.com/hpsc/doc/public/display?sp4ts.oid=3D7271227&docId=
=3Demr_na-c04650594&docLocale=3Den_US
>=20
> 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 {Fla=
gs =3D 2 '\002', Reserved =3D "\000\002", '\000' <repeats 18 times>, GroupC=
ount =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 ti=
mes>,
>       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>, "@\0=
20\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 6553=
5}}}}}
> --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:
>=20
> --8<---------------cut here---------------start------------->8---
> (gdb) print affinity=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> $2 =3D {Mask =3D 131072, Group =3D 0, Reserved =3D {0, 0, 0}}=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> (gdb) set affinity.Mask=3D2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20
> (gdb) set affinity.Group=3D1
> --8<---------------cut here---------------end--------------->8---
>=20
> However, the same or possibly even stranger processor group setups can
> be created using boot options that force different organizations of
> processor groups.  There is an option to force a seperate processor
> group for each NUMA node and another one to force a specific number of
> groups.  The upshot is that even the first processor groups may not have
> the maximum number of processors present, so you need to check the
> number of active processors instead.  I couldn't find out if the
> processor mask is still guaranteed to be filled from the LSB contigously
> or whether one can rely on only the last group to have less than the
> first few.  It seems more prudent to check the group specific
> ActiveProcessorMask, although that significantly complicates the code.
> I don't think Windows can currently switch CPU online/offline when
> booted.
>=20
>=20
> 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).
>=20
>=20
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>=20
> Factory and User Sound Singles for Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlrNsxEACgkQ9TYGna5E
T6CulQ//etO9lg8aIZwPzJgFza0T1C1P0GaQaxG2yjNi8bRk0wLOaBlXW7ukjQ99
2FV6xbWIVZiarI+vbKFbxYjKuOd1arJm3CXQ+S8KTBz9JRjKG1rYjNdNpsCPwEkX
t4ebsDOqk2YlZZcPRQsFBdzJ/oMSXBxLXgWW1qyKBUzFm6AaZWVc85YBUgqU0fRf
PzK40PO+W8e+gnboFEysqw3gCg2e4PWuYNxpCgt7mnjyCcJmrS9Xvrn2pmg+xfFe
HLTCpayZeQZZ1nPkRu/0sB7ych1STo/gOwcABYW9wYLEtpKFoobbV/f47j5cSnaM
w4wCk1XtXBa2vkzaMUJ4CX4GL3csD0/DVhtOxmM7WwKEQvERN4Rs1ulqiI+TbKW6
2cK3UtVd1U+ywgGzGHXJlbAPaF5m8JjZXlyS4MGVyfdF4ZqM/VGXij4YhmT1n+S9
ACJqIQuCsuSub67zmf2mk+g30w0fFGvA8YFrpmy0QyHlnDWxqG8R6N1HmqOtlZP0
pDb2n7RivFd7iqyCv/YeUFtIxUxjBHW/poIjhwxG1Y8C3B9ylYw06AhKzDdMqyul
K6zqqD0bAaVg6mCGLlpw3tlYA8AsKJgksep31Lqzjj0TktuRO+rBOr5VcjOTYgKB
qrSPWm8d++T+cPneFGwu1LK+FTGW8QZc+LwECDVjMjxELbdkp+k=
=k88W
-----END PGP SIGNATURE-----

--Bqc0IY4JZZt50bUr--

- Raw text -