Re: [PATCH] atomic: Specify natural alignment for atomic_t

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Aug 27, 2025 at 05:17:19PM +1000, Finn Thain wrote:
> 
> On Mon, 25 Aug 2025, Peter Zijlstra wrote:
> 
> > On Mon, Aug 25, 2025 at 06:03:23PM +1000, Finn Thain wrote:
> > > 
> > > On Mon, 25 Aug 2025, Peter Zijlstra wrote:
> > > 
> > > > 
> > > > And your architecture doesn't trap on unaligned atomic access ?!!?!
> > > > 
> > > 
> > > Right. This port doesn't do SMP.
> > 
> > There is RMW_INSN which seems to imply a compare-and-swap instruction of 
> > sorts. That is happy to work on unaligned storage?
> > 
> 
> Yes, the TAS and CAS instructions are happy to work on unaligned storage. 
> 
> However, these operations involve an indivisible bus cycle that hogs the 
> bus to the detriment of other processors, DMA controllers etc. So I 
> suspect lock alignment would tend to shorten read-modify-write cycles, and 
> improve efficiency, when CONFIG_RMW_INSN is enabled.
> 
> Most m68k platforms will have CONFIG_RMW_INSN disabled, or else simply 
> don't implement TAS and CAS. In this case, lock alignment might still 
> help, just because L1 cache entries are long words. I've not tried to 
> measure this.

Fair enough; this sounds a little like the x86 LOCK prefix, it will work
on unaligned memory, but at tremendous cost (recent chips have an
optional exception on unaligned).

Anyway, I'm not opposed to adding an explicit alignment to atomic_t.
Isn't s32 or __s32 already having this?

But I think it might make sense to have a DEBUG alignment check right
along with adding that alignment, just to make sure things are indeed /
stay aligned.