Re: kern/58340: 64-bit atomic ops unusable for armv7: __HAVE_ATOMIC64_{OPS,LOADSTORE} confusion

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

The following reply was made to PR kern/58340; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58340: 64-bit atomic ops unusable for armv7:
 __HAVE_ATOMIC64_{OPS,LOADSTORE} confusion
Date: Thu, 27 Jun 2024 16:18:09 +0900

 Sorry for the late reply.
 
 On 2024/06/19 4:14, Taylor R Campbell wrote:
 >> Date: Tue, 18 Jun 2024 23:44:01 +0900
 >> From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
 >>
 >> (1) Shouldn't we document things explicitly in, e.g., SIZE AND ALIGNMENT
 >> section in atomic_loadstore(9)?
 > 
 > I added a paragraph about this.  Does that help?
 
 Thanks, this helps much! I'll send pull up request to netbsd-10.
 
 >> (2) Can't we provide 64-bit atomic-ops API for ILP32 platforms? If no,
 >> do you speak about something by which we don't provide such runtime
 >> routines with our libc?
 > 
 > I don't understand.  Are you suggesting that we implement
 > atomic_load/store_* in terms of atomic_swap_*, or are you talking
 > about hash-locked atomic r/m/w like sparc32 and hppa, or what?
 > 
 > The point of __HAVE_ATOMIC64_LOADSTORE is to test whether the
 > architecture supports a _cheap_ atomic 64-bit load/store which can
 > safely be used without locking.  (Well, except for the hash-locked
 > architectures -- sparc32, hppa -- where atomic _stores_ can't be done
 > cheaply at all because they have to coordinate with the hash-locked
 > CAS anyway.)
 > 
 > So while it would be possible in principle (in the kernel, at least,
 > with all code cooperating in the protocol) to use a hash-locked scheme
 > for 64-bit atomic_load/store_*, this is almost certainly a waste --
 > better to just use an application-specific lock for better performance
 > and easier reasoning.
 
 Thank you very much for clear explanation. So, IIUC:
 
 (1) Some codes can be written much simpler if 64-bit atomic ops always
      available.
 
 (2) On the other hand, it adds performance penalty for ILP32 platforms.
 
 (3) Therefore, our policy (at the moment, at least) is not to allow
      MI codes depending on 64-bit atomic ops.
 
 Right? This situation is similar to libc, which is what I meant in
 my cryptic question in the previous message ;)
 
 Thanks,
 rin