[PATCH v4 00/15] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8
Ard Biesheuvel
ardb at kernel.org
Thu May 18 11:13:08 PDT 2023
On Thu, 18 May 2023 at 19:56, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> On Thu, May 18, 2023 at 10:34 AM Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> >
> > That's the fourth version of the series reducing the kmalloc() minimum
> > alignment on arm64 to 8 (from 128).
For the series:
Tested-by: Ard Biesheuvel <ardb at kernel.org> # tx2
and I am seeing lots of smaller allocations, all of which would have
otherwise taken up 128 or 256 bytes:
kmalloc-192 6426 6426 192 42 2 : tunables 0 0
0 : slabdata 153 153 0
kmalloc-128 9472 9472 128 64 2 : tunables 0 0
0 : slabdata 148 148 0
kmalloc-96 15666 15666 96 42 1 : tunables 0 0
0 : slabdata 373 373 0
kmalloc-64 21952 21952 64 64 1 : tunables 0 0
0 : slabdata 343 343 0
kmalloc-32 23424 23424 32 128 1 : tunables 0 0
0 : slabdata 183 183 0
kmalloc-16 41216 41216 16 256 1 : tunables 0 0
0 : slabdata 161 161 0
kmalloc-8 77846 80384 8 512 1 : tunables 0 0
0 : slabdata 157 157 0
The box is fully DMA coherent, of course, so this doesn't really tell
us whether the swiotlb DMA bouncing stuff works or not.
>
> Lovely. On my M2 Macbook air, I right now have about 24MB in the
> kmalloc-128 bucket, and most of it is presumably just 16 byte
> allocations (judging by my x86-64 slabinfo).
>
> I guess it doesn't really matter when I have 16GB in the machine, but
> this has annoyed me for a while.
>
Yeah but surely the overhead in terms of D-cache footprint is a factor here too?
> It feels like this is ready for 6.5, no?
>
Yes, please...
More information about the linux-arm-kernel
mailing list