NetBSD Problem Report #58611

From www@netbsd.org  Fri Aug 16 18:48:54 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 558591A9242
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 16 Aug 2024 18:48:54 +0000 (UTC)
Message-Id: <20240816184853.07EBE1A9243@mollari.NetBSD.org>
Date: Fri, 16 Aug 2024 18:48:52 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: atomic_*_ni should have feature macro for usefulness
X-Send-Pr-Version: www-1.0

>Number:         58611
>Category:       kern
>Synopsis:       atomic_*_ni should have feature macro for usefulness
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 16 18:50:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The atomic_NetBSD_ni Foundation
>Environment:
>Description:
The atomic_*_ni functions, such as atomic_add_32_ni, only guarantee atomicity with respect to interruption, not with respect to other CPUs.

As such, they are sometimes much cheaper than the plain, non-ni versions, for example on x86 where atomic_add_32_ni is a matter of a single `addl $N,(%rX)' instruction which incurs no interprocessor synchronization like `lock addl $N,(%rX)' would.

However, on other architectures such as Arm, they do incur interprocessor synchronization.  So, for atomicity with respect to interrupts, it may be cheaper to use splhigh/splx around a regular non-atomic memory operation instead of atomic_*_ni.  (Except for the part where splhigh/splx is unreasonably costly on Arm, but that's a separate bug.)

Currently there's no good way to choose one or the other depending on which option is cheaper.
>How-To-Repeat:
plan to draft a change for https://gnats.NetBSD.org/58610
>Fix:
Annoying as feature macros are, it might be nice if there were a feature macro for this distinction, like __HAVE_CHEAP_ATOMIC_NI or something.

Mostly it'll be x86 where we __HAVE_ATOMIC_CHEAP_NI.  But I could imagine using RAS on non-x86 architectures too.

Home	PR Database Search