Re: Xe performance regression with recent IOMMU changes

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jan 21, 2026 at 02:02:16PM +0100, Francois Dugast wrote:
> I am reporting a slowdown in Xe caused by a couple of IOMMU changes. It
> can be observed during DMA mappings/unmappings required to issue copies
> between system memory and the device, when handling GPU faults. Not sure
> how other use cases or vendors are affected but below is the impact on
> execution times for BMG:
> 
> Before changes:
>   4KB
>     drm_pagemap_migrate_map_pages: 0.4 us
>     drm_pagemap_migrate_unmap_pages: 0.4 us
>   64KB
>     drm_pagemap_migrate_map_pages: 2.5 us
>     drm_pagemap_migrate_unmap_pages: 3.5 us
>   2MB
>     drm_pagemap_migrate_map_pages: 88 us
>     drm_pagemap_migrate_unmap_pages: 108 us
> 
> After changes:
>   4KB
>     drm_pagemap_migrate_map_pages: 0.7 us
>     drm_pagemap_migrate_unmap_pages: 0.7 us
>   64KB
>     drm_pagemap_migrate_map_pages: 3.5 us
>     drm_pagemap_migrate_unmap_pages: 10.5 us
>   2MB
>     drm_pagemap_migrate_map_pages: 102 us
>     drm_pagemap_migrate_unmap_pages: 330 us

I posted some more optimizations for these cases, it should reduce the
numbers.

This is the opposite of the benchmark numbers I ran which showed
significant gains as the page count and sizes increased.

But something weird is going on to see a 3x increase in unmap, that
shouldn't be just algorithm overhead. That almost seems like
additional IOTLB invalidation overhead or something else going wrong.

Is this from a system with the VT-d cache flushing requirement? That
logic changed around too and could have this kind of big impact.

Jason