[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