NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index