Hi David,
On Wed, Apr 22, 2020 at 2:17 PM David Laight David.Laight@aculab.com wrote:
From: Lee Jones lee.jones@linaro.org
Sent: 22 April 2020 12:20 From: Alexey Brodkin alexey.brodkin@synopsys.com
[ 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