On 9/15/26 17:33, T.J. Mercier wrote: > On Tue, Sep 15, 2026 at 1:41 AM Christian König > <[email protected]> wrote: >> >> 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. > > Overhead from compaction and reclaim to get 2M pages? That is disabled > for non-0 page orders here in HIGH_ORDER_GFP.
Ah! Thanks for pointing that out, I misread the code that __GFP_RECLAIM is ORed into the mask. But the question is still why? Without reclaim that is pretty much an useless feature on most x86 boxes. Regards, Christian. > >>> 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 >>> >>
