On Thu, 18 May 2023 at 19:56, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, May 18, 2023 at 10:34 AM Catalin Marinas > <catalin.marinas@xxxxxxx> 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@xxxxxxxxxx> # 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...
