From: "Adrián Larumbe" <adrian.larumbe@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Steven Price <steven.price@arm.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Akash Goel <akash.goel@arm.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>,
Simona Vetter <simona@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] drm/panthor: Actually check huge-page mapping on sparse regions
Date: Fri, 2 Oct 2026 00:04:32 +0100 [thread overview]
Message-ID: <ar7m8n18RJqU0p59@sobremesa> (raw)
In-Reply-To: <20260924-panthor-fix-partial-unmap-v2-4-59a68a1f9e14@collabora.com>
On 24.09.2026 13:04, Boris Brezillon wrote:
> With the recent changes to iova_mapped_as_huge_page(), the check for
> huge-page mapping of sparse BOs is actually simple:
>
> - for a sparse mapping, we know the BO offset any VA in this regions is
> va & (SZ_2M - 1)
> - the VA we're searching the BO offset for is the 2M-aligned
> aligned_va value
>
> This guarantees that the BO offset to check is always zero in that case.
>
> This is simple enough to let the code check if page 0 is a huge page
> and save the unmap+map dance when the dummy BO is not backed by a
> a huge page. So let's do that and kill the comment that says it's too
> complicated.
I've been thinking about the kind of IGT test I could write to validate this series. Other than maybe
expanding igt_panthor_vm_bind_sparse() so that it can take an offset argument, I cannot think of anything
else, because whether the dummy BO's backing pages form a THP or unmapping a subset of a sparse VA causes
unmap boundaries to be expanded is transparent to UM.
Maybe adding a specific module param that the IGT test would trigger to show debug information relevant
to the above? But it seems a bit of an overkill to me.
> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
> Reviewed-by: Akash Goel <akash.goel@arm.com>
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/gpu/drm/panthor/panthor_mmu.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/panthor/panthor_mmu.c
> index d2897099763e..01564d250adf 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -2337,18 +2337,18 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping, u64 va)
>
> return false;
> } else {
> - const struct page *pg = bo->backing.pages[bo_offset >> PAGE_SHIFT];
> struct panthor_vma *vma = container_of(mapping, struct panthor_vma, base);
> bool is_sparse = vma->flags & DRM_PANTHOR_VM_BIND_OP_MAP_SPARSE;
> + const struct page *pg;
>
> - /* If the unmapped VMA stands for a sparse mapping, always
> - * assume the backing storage is a THP, since the overhead of
> - * unmapping 2MiB worth of 4KiB pages and remapping some of
> - * them is offset by the logic of working out whether it's
> - * the opposite case right below.
> + /* BO offset on a sparse mapping is chosen so that 2M-aligned
> + * VAs point to the start of the BO. Since aligned_va (the
> + * address we check huge-page against) is 2M-aligned, the BO
> + * offset is guaranteed to be zero.
> + * Check panthor_fix_sparse_map_offset() for more details.
> */
> if (is_sparse)
> - return true;
> + bo_offset = 0;
>
> /* In case of shmem backing, we know we can only have a huge
> * mapping if the bo_offset is 2M aligned, meaning we can skip
> @@ -2357,6 +2357,7 @@ iova_mapped_as_huge_page(struct drm_gpuva *mapping, u64 va)
> if (!IS_ALIGNED(bo_offset, SZ_2M))
> return false;
>
> + pg = bo->backing.pages[bo_offset >> PAGE_SHIFT];
> return folio_size(page_folio(pg)) >= SZ_2M;
> }
> }
>
> --
> 2.55.0
Adrian Larumbe
next prev parent reply other threads:[~2026-10-01 23:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 11:04 [PATCH v2 0/5] drm/panthor: Fix partial unmaps, again Boris Brezillon
2026-09-24 11:04 ` [PATCH v2 1/5] drm/panthor: Avoid false positives in iova_mapped_as_huge_page() Boris Brezillon
2026-10-05 10:27 ` Steven Price
2026-09-24 11:04 ` [PATCH v2 2/5] drm/panthor: Fix iova_mapped_as_huge_page() for imported BOs Boris Brezillon
2026-10-05 10:28 ` Steven Price
2026-09-24 11:04 ` [PATCH v2 3/5] drm/panthor: Consolidate the is-huge-page-mapping test Boris Brezillon
2026-10-05 10:50 ` Steven Price
2026-09-24 11:04 ` [PATCH v2 4/5] drm/panthor: Actually check huge-page mapping on sparse regions Boris Brezillon
2026-10-01 23:04 ` Adrián Larumbe [this message]
2026-10-05 11:03 ` Steven Price
2026-10-05 11:53 ` Boris Brezillon
2026-10-05 15:31 ` Steven Price
2026-10-05 15:48 ` Boris Brezillon
2026-09-24 11:04 ` [PATCH v2 5/5] drm/panthor: Remove redundant panthor_fix_sparse_map_offset() call Boris Brezillon
2026-10-05 11:03 ` Steven Price
2026-10-01 22:49 ` [PATCH v2 0/5] drm/panthor: Fix partial unmaps, again Adrián Larumbe
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=ar7m8n18RJqU0p59@sobremesa \
--to=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=akash.goel@arm.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/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.