From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35001 invoked by alias); 26 Apr 2019 08:44:21 -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 34984 invoked by uid 89); 26 Apr 2019 08:44:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HTo:U*cygwin-developers, heres, here's, membership X-HELO: m0.truegem.net Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Apr 2019 08:44:19 +0000 Received: from localhost (mark@localhost) by m0.truegem.net (8.12.11/8.12.11) with ESMTP id x3Q8iG03048301 for ; Fri, 26 Apr 2019 01:44:16 -0700 (PDT) (envelope-from mark@maxrnd.com) Date: Fri, 26 Apr 2019 08:44:00 -0000 From: Mark Geisert To: cygwin-developers@cygwin.com Subject: Re: Implement sched_[gs]etaffinity() In-Reply-To: <20190417075712.GX3599@calimero.vinschen.de> Message-ID: References: <20190411082516.GN4248@calimero.vinschen.de> <20190411083745.GO4248@calimero.vinschen.de> <20190412074533.GT4248@calimero.vinschen.de> <201904 <20190417075712.GX3599@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00052.txt.bz2 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 apply to all >>>> groups? >>> >>> Maybe https://go.microsoft.com/fwlink/p/?linkid=147914 helps? >>> >>> "If the number of logical processors exceeds the maximum group size, >>> Windows creates multiple groups by splitting the node into n groups, >>> where the first n-1 groups have capacities that are equal to the group >>> size." >> >> Great; thanks for that. >> >>> [...] >>> Therefore: >>> >>> WORD cpu_group = cpu_number / num_cpu_per_group; >>> KAFFINITY cpu_mask = 1L << (cpu_number % num_cpu_per_group); >>> >>> That also means the transposition between the groupless linux system >>> and the WIndows system is fairly easy. >> >> Yes, dealing with an array of unsigned longs vs bitblt ops FTW. I've been doing research to more fully understand the non-symmetric API for Windows affinity ops. I came across a non-MS document online that discusses affinity on Windows with >64 CPUs. The author works on "Process Lasso", a product that attempts to balance performance of apps across CPUs. Anyway, he says processors are divided evenly among groups. One reason for this is that Windows allocates new processes round-robin among the processor 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-windows/ 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. I don't think the code I've got is robust enough to submit yet. I suppose 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. ..mark