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