All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Aaron Lewis" <aaronlewis@google.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] vfio/type1: Periodically try rescheduling when unmapping
Date: Tue, 14 Jul 2026 21:15:36 +0000	[thread overview]
Message-ID: <20260714211537.6AB911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714210303.3967981-2-aaronlewis@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The use of `BIT(PUD_ORDER)` to rate-limit `cond_resched()` evaluates to incorrectly large values on architectures with large page sizes, failing to prevent the scheduler stall.
--

--- Patch [1]: [PATCH 1/2] vfio/type1: Periodically try rescheduling when unmapping ---
commit 2d6c55cffed789bb39f187cfc28ac1de6edd70b2
Author: Aaron Lewis <aaronlewis@google.com>

vfio/type1: Periodically try rescheduling when unmapping

This commit adds a cond_resched() to the inner loop of vfio_unmap_unpin()
to prevent CPU stalls during the unmapping of large DMA regions. It
attempts to rate limit the reschedule check to once per 1GB using
BIT(PUD_ORDER).

> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
[ ... ]
> @@ -1196,6 +1197,8 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma,
>  			next = iommu_iova_to_phys(domain->domain, iova + len);
>  			if (next != phys + len)
>  				break;
> +			if ((++i % BIT(PUD_ORDER)) == 0)
> +				cond_resched();

[Severity: Medium]
Will this rate limit fail to prevent scheduler stalls on architectures with
large page sizes?

On an ARM64 system configured with 64KB pages, PUD_SHIFT is 42 and PAGE_SHIFT
is 16, resulting in a PUD_ORDER of 26. BIT(26) evaluates to 67,108,864 loop
iterations.

Since each iteration processes PAGE_SIZE (64KB), the loop would process 4TB
of contiguous memory before calling cond_resched(). As noted in the commit
message, 67 million loop iterations can take over 1 second, which vastly
exceeds the 100ms scheduler tick limit.

Could this use a constant size limit instead, such as (SZ_1G >> PAGE_SHIFT),
to ensure the interval remains consistent across different architectures and
page sizes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714210303.3967981-1-aaronlewis@google.com?part=1

  reply	other threads:[~2026-07-14 21:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 21:03 [PATCH 0/2] vfio/iommufd: Prevent scheduler warnings when unmapping large regions Aaron Lewis
2026-07-14 21:03 ` [PATCH 1/2] vfio/type1: Periodically try rescheduling when unmapping Aaron Lewis
2026-07-14 21:15   ` sashiko-bot [this message]
2026-07-14 21:03 ` [PATCH 2/2] iommufd: Periodically reschedule " Aaron Lewis
2026-07-14 21:34   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260714211537.6AB911F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=aaronlewis@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.