From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 1462D3858CD1 for ; Sun, 3 Sep 2023 03:50:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1462D3858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 3833oexF054726 for ; Sat, 2 Sep 2023 20:50:40 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 50-1-247-226.fiber.dynamic.sonic.net(50.1.247.226), claiming to be "[192.168.4.101]" via SMTP by m0.truegem.net, id smtpdV0kCat; Sat Sep 2 20:50:36 2023 Subject: Re: posix thread scaling issue To: cygwin@cygwin.com References: <550e8950-8f7a-4765-b23e-57d0e710fde0@jeffunit.com> <2cfbcf8d-911f-a64b-8916-12b005c9f6f6@Shaw.ca> <07386659-68b3-a35d-1402-22684f8e5755@Shaw.ca> From: Mark Geisert Message-ID: <1a894e01-0dee-7a14-d94a-40034b88275f@maxrnd.com> Date: Sat, 2 Sep 2023 20:50:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <07386659-68b3-a35d-1402-22684f8e5755@Shaw.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi folks, Brian Inglis via Cygwin wrote: > On 2023-09-02 12:27, jeff via Cygwin wrote: [...] >> When I run cinebench, I can get to 100% cpu utulization (at around 3ghz) on >> windows. > > Chances are the benchmark is designed to handle that: > > "When the program is running inside the group, unless it is processor group aware, > then it can only access other threads in the same group. This means that if a > multi-threaded program can use 128 threads, if it isn’t built with processor > groups in mind, then it might only spawn with access to 64." > > I also do not know how you would program for that in Cygwin to map onto the > equivalent Windows function required. > > Perhaps one of the developers involved could comment here? Cygwin doesn't know (at user level) about processor groups as that's a Windows construct. Cygwin does know about processor affinity and treats all available processors as a contiguous set, like Linux does, up to 1024 in size. One uses 'taskset' from the util-linux package to assign processes to specific processor(s). One can deal with thread affinity using pthread_get_affinity_np() and pthread_set_affinity_np() functions provided by the Cygwin DLL. These are modeled after the same-named functions in Linux. The internals of these functions do have to work within the Windows processor group constraints, so not all plausible set-affinity operations are allowed by Windows. Briefly, you can't move a thread outside the processor group it's currently in; you have to move its process to the new group first. HTH, ..mark