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:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; q=dns; s=default; b=FFHrw
	lq9GolY8nkgsSI65QWR76IxPWJinv36mw25LZC/aEHRcmmpTQ0sUJwzJQHT+KpB3
	RKCZKHtvVm68QRIKvvu1LJgKogWOeImrRW+M/wqRIHtVGrnJgZU7SzdMOp/YFCv8
	a2EdNhiZpd9GRMKCFAPVXhaA32JnMYrN/XK+Ik=
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:from:to:subject:references:date:in-reply-to
	:message-id:mime-version:content-type; s=default; bh=p21U4gEhqr2
	+HDhlSMt6x5vTQ6Y=; b=CCNxSbrRoBZqEwfs3F8bRB2Mf3dU/5oGWeVmv9V4zg7
	mpiowiwJNEzhUr4/jH2fov1MOBhpoPayqb5fGPG5ZEPOns03u0X4y1iyS+gDdm8s
	febn2txyEy9/bUtWN/XXpEVYMV9r1qKX7XrTqTWfmMSP4vJY79iNmUYXqKlGPaOU
	=
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=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=indicating, shifted
X-HELO:	mx009.vodafonemail.xion.oxcs.net
From:	Achim Gratz <Stromeko AT nexgo DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Re: /proc/cpuinfo vs. processor groups
References:	<878t9vt3vs DOT fsf AT Rainer DOT invalid> <20180411070241 DOT GJ29703 AT calimero DOT vinschen DOT de> <20180411092841 DOT GL29703 AT calimero DOT vinschen DOT de> <20180411104921 DOT GN29703 AT calimero DOT vinschen DOT de>
Date:	Wed, 11 Apr 2018 19:02:49 +0200
In-Reply-To:	<20180411104921.GN29703@calimero.vinschen.de> (Corinna Vinschen's message of "Wed, 11 Apr 2018 12:49:21 +0200")
Message-ID:	<87vacxwu9y.fsf@Rainer.invalid>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version:	1.0
X-VADE-STATUS:	LEGIT

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

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

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.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -