NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/58611: atomic_*_ni should have feature macro for usefulness
>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 |
Main Index |
Thread Index |
Old Index