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. > > 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 > > >
