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

On Thu, Jul 16, 2026 at 6:20 AM Jason Gunthorpe <[email protected]> wrote:
>
> On Wed, Jul 15, 2026 at 03:07:42PM -0700, Aaron Lewis wrote:
> > On Wed, Jul 15, 2026 at 11:11 AM Jason Gunthorpe <[email protected]> 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/[email protected]/
> > > >
> > > > And profiled using the bpftrace tooling proposed here:
> > > >  - https://lore.kernel.org/kvm/[email protected]/
> > >
> > > 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/[email protected]/
> > >
> > > 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

Any idea what a minimum proposal would look like?  Looking at the
series it all looks pretty relevant given the goal would be to have
iova_to_phys_length() land.

Aaron