[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9453560f-2240-ab6f-84f1-0bb99d118998@linux-m68k.org>
Date: Wed, 27 Aug 2025 17:17:19 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Peter Zijlstra <peterz@...radead.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Lance Yang <lance.yang@...ux.dev>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Masami Hiramatsu <mhiramat@...nel.org>, Eero Tamminen <oak@...sinkinet.fi>,
Will Deacon <will@...nel.org>, stable@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t
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.
Powered by blists - more mailing lists