On Thu, Jun 08, 2023 at 10:05:58AM +0200, Ard Biesheuvel wrote: > On Thu, 8 Jun 2023 at 07:45, Isaac Manjarres <isaacmanjarres@xxxxxxxxxx> wrote: > > > > On Wed, May 31, 2023 at 8:48 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > Here's version 6 of the series reducing the kmalloc() minimum alignment > > > on arm64 to 8 (from 128). There are patches already to do the same for > > > riscv (pretty straight-forward after this series). > > Thanks, Catalin for getting these patches out. Please add my "Tested-by:" tag > > for the series: > > > > Tested-by: Isaac J. Manjarres <isaacmanjarres@xxxxxxxxxx> > > > > With the first 11 patches, I observed a reduction of 18.4 MB > > in the slab memory footprint on my Pixel 6 device. After applying the > > rest of the patches in the series, I observed a total reduction of > > 26.5 MB in the > > slab memory footprint on my device. These are great results! > > > > It would also be good to get an insight into how much bouncing is > going on in this case, given that (AFAIK) Pixel 6 uses non-cache > coherent DMA. I enabled the "swiotlb_bounced" trace event from the kernel command line to see if anything was being bounced. It turns out that for Pixel 6 there are non-coherent DMA transfers occurring, but none of the transfers that are in either the DMA_FROM_DEVICE or DMA_BIDIRECTIONAL directions are small enough to require bouncing. --Isaac P.S. I noticed that the trace_swiotlb_bounced() tracepoint may not be invoked even though bouncing occurs. For example, in the dma-iommu path, swiotlb_tbl_map_single() is called when bouncing, instead of swiotlb_map(), which is what ends up calling trace_swiotlb_bounced(). Would it make sense to move the call to trace_swiotlb_bounced() to swiotlb_tbl_map_single() since that function is always invoked?
