Hi David,
On Wed, Apr 22, 2020 at 2:17 PM David Laight <David.Laight@xxxxxxxxxx> wrote:
> From: Lee Jones <lee.jones@xxxxxxxxxx>
> > Sent: 22 April 2020 12:20
> > From: Alexey Brodkin <alexey.brodkin@xxxxxxxxxxxx>
> >
> > [ Upstream commit a66d972465d15b1d89281258805eb8b47d66bd36 ]
> >
> > Initially we bumped into problem with 32-bit aligned atomic64_t
> > on ARC, see [1]. And then during quite lengthly discussion Peter Z.
> > mentioned ARCH_KMALLOC_MINALIGN which IMHO makes perfect sense.
> > If allocation is done by plain kmalloc() obtained buffer will be
> > ARCH_KMALLOC_MINALIGN aligned and then why buffer obtained via
> > devm_kmalloc() should have any other alignment?
> >
> > This way we at least get the same behavior for both types of
> > allocation.
>
> Anyone any idea how much difference it would actually make
> to align all architectures to at least 32-bits (or even 64-bits)?
>
> I think the only times it would make a difference would be for
> allocations that (for example, 62 bytes on m68k) just
> fit in a 64 byte block - so suddenly grow to 128 bytes.
> (Or whatever granularity the allocator uses).
I believe ARCH_KMALLOC_MINALIGN is already at least 16 _bytes_
on all architectures (up to at last 128, perhaps even 256?).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
