From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124702 invoked by alias); 26 Apr 2019 08:53:19 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 124690 invoked by uid 89); 26 Apr 2019 08:53:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-103.2 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=nah, worries, hurry, H*F:D*cygwin.com X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Apr 2019 08:53:17 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N0nSN-1gYjGh2CiD-00wm0C for ; Fri, 26 Apr 2019 10:53:14 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id BEA11A80431; Fri, 26 Apr 2019 10:53:13 +0200 (CEST) Date: Fri, 26 Apr 2019 08:53:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Implement sched_[gs]etaffinity() Message-ID: <20190426085313.GD13355@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20190411082516.GN4248@calimero.vinschen.de> <20190411083745.GO4248@calimero.vinschen.de> <20190412074533.GT4248@calimero.vinschen.de> <20190417075712.GX3599@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-04/txt/msg00053.txt.bz2 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2687 On Apr 26 01:44, Mark Geisert wrote: > On Wed, 17 Apr 2019, Corinna Vinschen wrote: > > On Apr 16 21:31, Mark Geisert wrote: > > > On Tue, 16 Apr 2019, Corinna Vinschen wrote: > > > > On Apr 16 01:19, Mark Geisert wrote: > > > > > Anybody know if one can > > > > > depend on the group membership of the first processor group to ap= ply to all > > > > > groups? > > > >=20 > > > > Maybe https://go.microsoft.com/fwlink/p/?linkid=3D147914 helps? > > > >=20 > > > > "If the number of logical processors exceeds the maximum group size, > > > > Windows creates multiple groups by splitting the node into n group= s, > > > > where the first n-1 groups have capacities that are equal to the g= roup > > > > size." > > >=20 > > > Great; thanks for that. > > >=20 > > > > [...] > > > > Therefore: > > > >=20 > > > > WORD cpu_group =3D cpu_number / num_cpu_per_group; > > > > KAFFINITY cpu_mask =3D 1L << (cpu_number % num_cpu_per_group); > > > >=20 > > > > That also means the transposition between the groupless linux system > > > > and the WIndows system is fairly easy. > > >=20 > > > Yes, dealing with an array of unsigned longs vs bitblt ops FTW. >=20 > I've been doing research to more fully understand the non-symmetric API f= or > Windows affinity ops. I came across a non-MS document online that discus= ses > affinity on Windows with >64 CPUs. The author works on "Process Lasso", a > product that attempts to balance performance of apps across CPUs. >=20 > Anyway, he says processors are divided evenly among groups. One reason f= or > this is that Windows allocates new processes round-robin among the proces= sor > groups. This won't balance properly if some groups have more processors > than other groups. Here's a link to the doc: > https://bitsum.com/general/the-64-core-threshold-processor-groups-and-win= dows/ >=20 > I'm not trying to muddy the waters, I'm just trying to figure out if there > are different processor group assignment methods for different kinds of > systems, SMP vs NUMA for instance. That's what the __get_cpus_per_group function in miscfuncs.cc is for, so you know the number of CPUs per group, and the transposition from grouped vs. linear representation and vice versa is no problem. The non-NUMA vs. NUMA problem is just some under the hood design which tries to keep closely related nodes together if possible. > I don't think the code I've got is robust enough to submit yet. I suppos= e I > could ship what should work, i.e., single-group processes and threads and > just return ENOSYS for multi-group ops. Or just hold off 'til done. Nah, no worries. We're in no hurry. Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlzCxvkACgkQ9TYGna5E T6C1ww//V10RBqgedatMgMfoOxvYT9ZT3bSRNMjuc/cY5I7XZFpXq4hcAleHP+G9 56k2Az2BgKm0NUhaZlCBSlV1jw9/3jBFlUMWcWDKWYdgLvoRcLzXaGitC2Hiwphz n7eA29gzO6zDRPPmG5dBT77r8zMUoPtIL4M1ypAWrfdGys5dTFxleUSUfHZibN7Z lAz5zhjI0op+57RzdNFcaNNFomfuBJnAtgQg8OM5DC63YxsnGH6UwxP89vzvQBL6 FgBcVumk+oVbdTLwHjN2PphTHK22Og7U/A7awKpk5/mr0PgOZFT76FlBLka649Gg fSvjXX6C4UREIAPwgW41GG0xarzsLdlFBiCqMoh09Gycc46MiUdodf37SH6qVKUq ciJKaADaphhkTrJbvA7GR5TYw1zZhX4J9ZlI/RO83IsdEI1bTnL30uMXfiy08Kb/ /stVAOLS77dHsU+4Yfyryhh4BNs9O24HB9K/1DJinLY2DOd9QSvDCWE/1GP2i/Tf 0t5xbc/E1ugQtWzG1qaz1qhf/S7Ck/txGuSi0pwAsmsyz+JL+qAzeG3CbsEW3ac5 DWzXcyhNYh8eoPOGNsvCZ3fjlmxqyapXBPsHslLp/n7Oxk/DvCE533ieZG0ElnAn NY2+zPolzC4LN1WdiwLaXwbHv8vJaFywd0qKciKHrPsNDeGvKQE= =gWIF -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb--