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:	<e89e7440-553f-495d-95da-9ac7c7aa71dd@maxrnd.com>
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>
In-Reply-To:	<378d90a0-bff5-36d1-d1f7-8a28e046af2a@t-online.de>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Mark Geisert via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Mark Geisert <mark AT maxrnd DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
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

- Raw text -