[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdUKgMfL+1EnkZbbqNqTv4aMs_XWocXxq5jVGeOMaQXnDQ@mail.gmail.com>
Date: Mon, 1 Sep 2025 10:51:22 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Eero Tamminen <oak@...sinkinet.fi>
Cc: Finn Thain <fthain@...ux-m68k.org>, Andrew Morton <akpm@...ux-foundation.org>,
Lance Yang <lance.yang@...ux.dev>, Masami Hiramatsu <mhiramat@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Will Deacon <will@...nel.org>, stable@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t
Hi Eero,
On Tue, 26 Aug 2025 at 17:22, Eero Tamminen <oak@...sinkinet.fi> wrote:
> On 25.8.2025 5.03, Finn Thain wrote:
> > Some recent commits incorrectly assumed the natural alignment of locks.
> > That assumption fails on Linux/m68k (and, interestingly, would have failed
> > on Linux/cris also). This leads to spurious warnings from the hang check
> > code. Fix this bug by adding the necessary 'aligned' attribute.
> [...]
> > Reported-by: Eero Tamminen <oak@...sinkinet.fi>
> > Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58Rc1_0g@mail.gmail.com/
> > Fixes: e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker")
> > Signed-off-by: Finn Thain <fthain@...ux-m68k.org>
> > ---
> > I tested this on m68k using GCC and it fixed the problem for me. AFAIK,
> > the other architectures naturally align ints already so I'm expecting to
> > see no effect there.
>
> Yes, it fixes both of the issues (warnings & broken console):
> Tested-by: Eero Tamminen <oak@...sinkinet.fi>
>
> (Emulated Atari Falcon) boot up performance with this is within normal
> variation.
>
> On 23.8.2025 10.49, Lance Yang wrote:
> > Anyway, I've prepared two patches for discussion, either of which should
> > fix the alignment issue :)
> >
> > Patch A[1] adjusts the runtime checks to handle unaligned pointers.
> > Patch B[2] enforces 4-byte alignment on the core lock structures.
> >
> > Both tested on x86-64.
> >
> > [1]
> https://lore.kernel.org/lkml/20250823050036.7748-1-lance.yang@linux.dev
> > [2] https://lore.kernel.org/lkml/20250823074048.92498-1-
> > lance.yang@...ux.dev
>
> Same goes for both of these, except that removing warnings makes minimal
> kernel boot 1-2% faster than 4-aligning the whole struct.
That is an interesting outcome! So the gain of naturally-aligning the
lock is more than offset by the increased cache pressure due to wasting
(a bit?) more memory.
Do you know what was the impact on total kernel size?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists