Message ID | 20230518173403.1150549-1-catalin.marinas@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8 | expand |
On Thu, May 18, 2023 at 10:34 AM Catalin Marinas <catalin.marinas@arm.com> wrote: > > That's the fourth version of the series reducing the kmalloc() minimum > alignment on arm64 to 8 (from 128). 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. It feels like this is ready for 6.5, no? Linus
On Thu, 18 May 2023 at 19:56, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, May 18, 2023 at 10:34 AM Catalin Marinas > <catalin.marinas@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@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...
On Thu, May 18, 2023 at 10:56:24AM -0700, Linus Torvalds wrote: > On Thu, May 18, 2023 at 10:34 AM Catalin Marinas > <catalin.marinas@arm.com> wrote: > > > > That's the fourth version of the series reducing the kmalloc() minimum > > alignment on arm64 to 8 (from 128). > > 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. > > It feels like this is ready for 6.5, no? From an implementation approach perspective, I definitely target 6.5. But I need help with testing this, especially the iommu bits (can buy Robin some beers ;)).
On Thu, May 18, 2023 at 08:13:08PM +0200, Ard Biesheuvel wrote: > On Thu, 18 May 2023 at 19:56, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > On Thu, May 18, 2023 at 10:34 AM Catalin Marinas > > <catalin.marinas@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@kernel.org> # tx2 [...] > The box is fully DMA coherent, of course, so this doesn't really tell > us whether the swiotlb DMA bouncing stuff works or not. Thanks. On TX2, I forced the bouncing with: diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h index 43bf50c35e14..9006bf680db0 100644 --- a/include/linux/dma-map-ops.h +++ b/include/linux/dma-map-ops.h @@ -296,7 +296,7 @@ static inline bool dma_kmalloc_safe(struct device *dev, * is coherent or the direction is DMA_TO_DEVICE (non-desctructive * cache maintenance and benign cache line evictions). */ - if (dev_is_dma_coherent(dev) || dir == DMA_TO_DEVICE) + if (/*dev_is_dma_coherent(dev) || */dir == DMA_TO_DEVICE) return true; return false;