DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52A8g2UW2589913 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52A8g2UW2589913 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=SpfkcDQB X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 498503858405 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741596120; bh=HhPATMXhEVJqjT0H50taAEVo8gfVyQI1aBMyABgxUfk=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=SpfkcDQB1wR3mrkeIOcGaVYSxkw9XW2onCIN0n1tideGGVrkEHOfQrzOphqRvdJWh nTHPyLxDwhcfSPsgEbVliirXkiEaIxRfE3Mir4zC8QQr794g0fUdxmKHKAkkQ+Kj8B mQ1hZvWrYQADYbDt9SUH1ySZevJzMS4SYZlkDBMg= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4DCEC3858D38 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4DCEC3858D38 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741596057; cv=none; b=XRglcZ2trvcpgHoZKiOkK8RuIPPo5I6jhw6qNKN6tAaJWeztfWmAg8iSJ0F+Ybgih41ZBIUvxakm/r2WzVOsTi0wrJuoFGXG7Buu2OU11yeJUB5Ghf7V8B+tO4+zh4NvuEAFRpU9Pq1xXxFyLlRb56FOYyoCrVnSPR/2YXwYgUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741596057; c=relaxed/simple; bh=xepG23PR1XYof+laNTFdoELLoABkDM2L/5GZ3BYjcgY=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=XgkhxPcFKOrPJXP8AUmB0a94FmjMc7tlTT2FYwFwsL/yW2XcHqC7zFqOWRF2hHuA+u6Kyx5z6t8/fkzK+7GTcEcTrceJiskGVOwmoQVePVmXt+BfonLNOXgqUMHz8q14WCUsW916kkwI7aBK/20KXCeyLj3Su5zESc0NhaYzRsM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4DCEC3858D38 Message-ID: Date: Mon, 10 Mar 2025 01:40:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: sched_getaffinity() always returns the full cpu mask To: cygwin AT cygwin DOT com References: <378d90a0-bff5-36d1-d1f7-8a28e046af2a AT t-online DOT de> Content-Language: en-US In-Reply-To: <378d90a0-bff5-36d1-d1f7-8a28e046af2a@t-online.de> X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mark Geisert via Cygwin Reply-To: Mark Geisert Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 52A8g2UW2589913 Hi Christian, On 3/8/2025 9:11 AM, Christian Franke via Cygwin wrote: > Testcase: > > $ grep processor /proc/cpuinfo | tail -1 # i7-14700K > processor       : 27 > > $ sleep 60 & taskset 0x1 sleep 60 & > [1] 62094 > [2] 62095 > > $ taskset -p 62094 > pid 62094's current affinity mask: fffffff > > $ taskset -p 62095 > pid 62095's current affinity mask: fffffff This may well be the first test of Cygwin's affinity support on a system where the cpu mask bit length isn't a power of 2. I did test such but seeing it on hardware is another matter. Are there in fact just 28 hardware processors on this system? Does Windows (or Linux for that matter) allow one to set cpu group size? I would think the BIOS would want control over that, with the OSs just providing read access to what was chosen. For 28 processors, a single group of 28 processors, or either 4 groups of 7 procs, or 7x4, or even 2x14 or 14x2 are plausible if not all useful. > Another test shows that the affinity mask is correctly set to 0x1 by > sched_setaffinity(). That's good to hear. > In sched.cc:__sched_getaffinity_sys(), GetProcessAffinityMask() is > called, but its 'procmask' result is never used. The returned cpu_set is > build using groupmask(__get_cpus_per_group ()) which is constant, here > 0xfffffff. The original commit 641ecb07 likely worked (until 687c4bad^) > on older Windows versions which did not support cpu groups. Oops on the unused result. I think the intent was to fold it into the process group info to return combined mask values (somehow). > I don't know how to fix this for systems with more than one cpu group, > so no patch provided. The notion I had during implementation was that we're emulating the Linux view of affinities if that differs from Windows. The existing code is intended to take multiple cpu groups into account because the complete cpu mask for the system is being considered and/or returned. I will re-read the MSDN docs for Windows' affinity functions. They may well have been updated since I last read them. > It might be needed to handle interesting corner cases: "If the process > had explicitly set the affinity of one or more of its threads outside of > the process' primary group, the function returns zero for both affinity > masks." > https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase- > getprocessaffinitymask Yeesh, those cases are the kind of gotchas we want to find because Windows may well differ from Linux in how they're handled. Thanks, ..mark -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple