On 9/14/26 23:22, Davidlohr Bueso wrote: > With 4KB base pages, the system heap allocates buffers in 1MB, 64KB > and 4KB chunks. The conventional Intel VT-d second-stage and AMD-Vi v2 > page-table formats, and Arm SMMU's 64-bit long-descriptor format with > a 4KB translation granule, define 4KB pages and 2MB/1GB large-page > mappings, but no 1MB leaf. A 1MB chunk therefore requires 256 4KB leaf > entries unless it can be combined with adjacent chunks into a > suitably aligned larger mapping.
Yes, it was an intentional design choice to *NOT* optimize for AMD nor Intels IOMMU here. > Adding a 2MB allocation order provides naturally aligned, physically > contiguous chunks matching the 2MB leaf size, without relying on this > being accidental for separate smaller allocations. The new cost > is one failed order-9 attempt (keeping current large allocation semantics) > per buffer when 2MB pages are exhausted. We have plenty of experience with this with TTM and the overhead this results in is usually not acceptable. > Two benchmarks, measured on an AMD EPYC 7313P. Why in the world are you testing the system heap on an AMD EPYC system? AMD clearly doesn't recommend using the system heap on those boxes for ROCm, so I'm really wondering what combination of HW you have here? Regards, Christian. > > (i) Mapping, into an idle NVMe function's translated DMA-FQ domain, > measuring map/unmap: with the v1 page table restricted to 4K/2M/1G > (amd_iommu=v2_pgsizes_only), a 1GB buffer goes from 1024 1MB chunks, > only one of whose 2MB windows was superpage-mappable in that run, to > 512 2MB chunks with all 512 mappable. dma_buf_map_attachment() costs > decrease by ~16x on average with ~32x for the worst cases. Unmapping > that buffer drops from ~500 us to 1.25 us. > > (ii) A microbench that measures the cost of DMA_HEAP_IOCTL_ALLOC+close > across various thread counts decreases by factors of ~3-7x alleviating > allocator's zone->lock contention by being PMD order and therefore is > pcpu list eligible. Once the buffer size is large enough then the cost > of the zeroing takes over. > > Signed-off-by: Davidlohr Bueso <[email protected]> > --- > drivers/dma-buf/heaps/system_heap.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma-buf/heaps/system_heap.c > b/drivers/dma-buf/heaps/system_heap.c > index c8959eadc71d..621cf238ef97 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -55,14 +55,15 @@ struct dma_heap_attachment { > #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ > | __GFP_NORETRY) & ~__GFP_RECLAIM) \ > | __GFP_COMP) > -static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; > +static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, > + HIGH_ORDER_GFP, LOW_ORDER_GFP}; > /* > - * The selection of the orders used for allocation (1MB, 64K, 4K) is designed > - * to match with the sizes often found in IOMMUs. Using order 4 pages instead > - * of order 0 pages can significantly improve the performance of many IOMMUs > - * by reducing TLB pressure and time spent updating page tables. > + * The selection of the orders used for allocation (2MB, 1MB, 64K, 4K) is > + * designed to match with the sizes often found in IOMMUs. Using larger order > + * pages instead of order 0 pages can significantly improve the performance > of > + * many IOMMUs by reducing TLB pressure and time spent updating page tables. > */ > -static const unsigned int orders[] = {8, 4, 0}; > +static const unsigned int orders[] = {9, 8, 4, 0}; > #define NUM_ORDERS ARRAY_SIZE(orders) > > static int system_heap_set_page_decrypted(struct page *page) > -- > 2.39.5 >
