From: sashiko-bot@kernel.org
To: "Mika Kuoppala" <mika.kuoppala@linux.intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/xe/tests: Cover a large write to an unaligned bo offset
Date: Tue, 27 Oct 2026 15:03:35 +0000 [thread overview]
Message-ID: <sashiko-outbox-186788@kernel.org> (raw)
In-Reply-To: <20261027145237.1862132-2-mika.kuoppala@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe/tests: 64B bounce loop in access_memory_test_unaligned_large_write()
--
commit 983819064579a8f3c33e9b1bc03bdf5b989cdcfe
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
drm/xe/tests: Cover a large write to an unaligned bo offset
This commit adds a KUnit test case to drivers/gpu/drm/xe/tests/xe_migrate.c
that writes and reads back a 16 MiB buffer object from an unaligned offset of
4 bytes using xe_migrate_access_memory() to exercise the
MAX_PREEMPTDISABLE_TRANSFER chunking path.
> diff --git a/drivers/gpu/drm/xe/tests/xe_migrate.c b/drivers/gpu/drm/xe/tests/xe_migrate.c
> index a9ef8f2dcebbf..715de366d33c0 100644
> --- a/drivers/gpu/drm/xe/tests/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/tests/xe_migrate.c
> @@ -1041,6 +1041,53 @@ static void access_memory_test_run_tile(struct xe_device *xe,
> kvfree(buf);
> }
>
> +static void access_memory_test_unaligned_large_write(struct kunit *test,
> + struct xe_tile *tile)
> +{
> + const u32 size = SZ_16M, offset = 4;
[ ... ]
> + xe_bo_lock(bo, false);
> + ret = xe_migrate_access_memory(tile->migrate, bo, offset, buf,
> + size - offset, true);
> + if (!ret) {
> + memset(buf, 0, size);
> + ret = xe_migrate_access_memory(tile->migrate, bo, offset, buf,
> + size - offset, false);
> + }
[Severity: Medium]
On discrete GPUs without MEM_COPY instruction support (where
xe->info.has_mem_copy_instr is false, such as DG1, DG2, ATS-M, and PVC), will
calling xe_migrate_access_memory() with offset = 4 for a 16 MiB transfer
fall into the 64-byte bounce-buffer loop for the entire buffer instead of
exercising the MAX_PREEMPTDISABLE_TRANSFER chunking path?
In drivers/gpu/drm/xe/tests/xe_migrate.c, access_memory_test_run_device()
calls access_memory_test_unaligned_large_write() on all discrete devices.
In drivers/gpu/drm/xe/xe_migrate.c, xe_migrate_access_memory() checks:
/* Use bounce buffer for small access and unaligned access */
if (!xe->info.has_mem_copy_instr &&
(!IS_ALIGNED(len, 4) ||
!IS_ALIGNED(page_offset, XE_CACHELINE_BYTES) ||
!IS_ALIGNED(offset, XE_CACHELINE_BYTES))) {
...
do {
int copy_bytes = min_t(int, bytes_left,
XE_CACHELINE_BYTES -
(offset & XE_CACHELINE_MASK));
...
err = xe_migrate_access_memory(m, bo,
offset &
~XE_CACHELINE_MASK,
bounce,
XE_CACHELINE_BYTES, 0);
...
if (write) {
...
err = xe_migrate_access_memory(m, bo,
offset & ~XE_CACHELINE_MASK,
bounce,
XE_CACHELINE_BYTES, write);
...
} while (bytes_left);
kfree(bounce);
return err;
}
Because offset = 4 is not aligned to XE_CACHELINE_BYTES (64),
!IS_ALIGNED(offset, XE_CACHELINE_BYTES) is true when
!xe->info.has_mem_copy_instr. Rather than bouncing only the unaligned head,
that loop processes all bytes_left (SZ_16M - 4) in 64-byte chunks.
For a 16 MiB write followed by a 16 MiB read, this performs 262,144 write
iterations (each doing two synchronous 64-byte xe_migrate_access_memory()
calls) plus 262,144 synchronous 64-byte read calls, totaling 786,432
sequential synchronous GPU jobs per tile and bypassing the main
MAX_PREEMPTDISABLE_TRANSFER loop on those platforms.
Should offset be aligned to XE_CACHELINE_BYTES (for example, offset = 64) on
!xe->info.has_mem_copy_instr platforms so that it remains unaligned to the
page and 256-byte pitch while still reaching the main transfer loop without
timing out?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261027145237.1862132-1-mika.kuoppala@linux.intel.com?part=2
next prev parent reply other threads:[~2026-10-27 15:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 14:52 [PATCH 1/2] drm/xe/migrate: Keep access_memory chunks within the transfer limit Mika Kuoppala
2026-10-27 14:52 ` [PATCH 2/2] drm/xe/tests: Cover a large write to an unaligned bo offset Mika Kuoppala
2026-10-27 15:03 ` sashiko-bot [this message]
2026-10-27 15:57 ` Matthew Auld
2026-10-27 18:04 ` Mika Kuoppala
2026-10-28 10:07 ` Matthew Auld
2026-10-27 15:26 ` [PATCH 1/2] drm/xe/migrate: Keep access_memory chunks within the transfer limit Matthew Auld
2026-10-27 15:37 ` Jan Maslak
2026-10-27 15:37 ` ✗ CI.checkpatch: warning for series starting with [1/2] " Patchwork
2026-10-27 15:40 ` ✓ CI.KUnit: success " Patchwork
2026-10-27 16:18 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-27 19:52 ` ✓ Xe.CI.FULL: " Patchwork
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=sashiko-outbox-186788@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=mika.kuoppala@linux.intel.com \
--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.