Re: [PATCH 0/2] vfio/iommufd: Prevent scheduler warnings when unmapping large regions

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jul 15, 2026 at 03:07:42PM -0700, Aaron Lewis wrote:
> On Wed, Jul 15, 2026 at 11:11 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Tue, Jul 14, 2026 at 09:03:01PM +0000, Aaron Lewis wrote:
> > > Both the Type1 IOMMU and IOMMUFD can be guilty of not playing nice with
> > > the scheduler during DMA unmapping on large regions (e.g., 256GB). Add
> > > rate-limited calls to cond_resched() to ensure this doesn't happen.
> > >
> > > This series was tested using the selftest proposed here:
> > >  - https://lore.kernel.org/kvm/20260701203311.326798-1-aaronlewis@google.com/
> > >
> > > And profiled using the bpftrace tooling proposed here:
> > >  - https://lore.kernel.org/kvm/20260630141152.3757722-2-aaronlewis@google.com/
> >
> > Given this is the same issue on both in the some place, I wonder if it
> > is better to try to get this series done:
> >
> > https://lore.kernel.org/linux-iommu/20260603151804.1963871-1-guanghuifeng@linux.alibaba.com/
> >
> > And put the cond sched inside the iova_to_phys_length() ?
> >
> > It would be fine to do things in steps, like add the
> > iova_to_phys_length() that just does the loops iommufd and vfio have
> > today with the additional cond sched inside which isn't such a big
> > task.
> >
> > Jason
> 
> Ah, I think that is really what I wanted, but I proposed a solution to
> get feedback quicker.  I'll wait for that series to be merged and
> reaccess if a cond_resched() is still needed.  I'll follow up here
> once I've had a chance to run these tests again with it included.

It seems kind of stalled, so IDK if you want to propose just a bit of
it that would be fine too

Jason