All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
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: Wed, 28 Oct 2026 10:07:07 +0000	[thread overview]
Message-ID: <bb850cb7-5564-47d5-ad6b-98c8cf8f9aa9@intel.com> (raw)
In-Reply-To: <87wlr3rpf1.fsf@mkuoppal-desk>

On 27/10/2026 18:04, Mika Kuoppala wrote:
> Matthew Auld <matthew.auld@intel.com> writes:
> 
>> On 27/10/2026 14:52, Mika Kuoppala wrote:
>>> Write a contiguous 16M bo from offset 4 with xe_migrate_access_memory()
>>> and read it back. Aligning the vram side leaves buf mid page, so the
>>> following full chunk has to stay within MAX_PREEMPTDISABLE_TRANSFER.
>>>
>>> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>
>> Do we know how long this test now takes? It is pulled into BAT I think.
>>
> 
> With BMG:
> 
> IGT-Version: 2.6-gfd2038445a (x86_64) (Linux: 7.3.0+ x86_64)
>    Using IGT_SRANDOM=1793110920 for randomisation
>    Starting subtest: xe_migrate
>    Starting dynamic subtest: xe_migrate_access_memory_kunit
>    Dynamic subtest xe_migrate_access_memory_kunit: SUCCESS (0.320s)
>    Subtest xe_migrate: SUCCESS (0.338s)

Ok, there is: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9663

Which hints that this was already very slow on ats (I think uses bounce 
buffer?). The sashiko report is maybe related? We could also just skip 
this on pre-xe2 going forward if that is simpler, since it is not really 
production. Up to you though.

>    
>> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> 
> Thanks,
> -Mika
> 
>>> ---
>>>    drivers/gpu/drm/xe/tests/xe_migrate.c | 50 +++++++++++++++++++++++++++
>>>    1 file changed, 50 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xe/tests/xe_migrate.c b/drivers/gpu/drm/xe/tests/xe_migrate.c
>>> index a9ef8f2dcebb..715de366d33c 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;
>>> +	struct xe_bo *bo;
>>> +	u32 j;
>>> +	u8 *buf;
>>> +	int ret;
>>> +
>>> +	buf = kvmalloc(size, GFP_KERNEL);
>>> +	if (!buf) {
>>> +		KUNIT_FAIL(test, "Failed to allocate buffer\n");
>>> +		return;
>>> +	}
>>> +
>>> +	bo = xe_bo_create_pin_map_novm(tile_to_xe(tile), tile, size,
>>> +				       ttm_bo_type_kernel,
>>> +				       XE_BO_FLAG_VRAM_IF_DGFX(tile), false);
>>> +	if (IS_ERR(bo)) {
>>> +		KUNIT_FAIL(test, "Failed to create bo: %pe\n", bo);
>>> +		goto free_buf;
>>> +	}
>>> +
>>> +	for (j = 0; j < size / sizeof(u32); j++)
>>> +		((u32 *)buf)[j] = j;
>>> +
>>> +	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);
>>> +	}
>>> +	xe_bo_unlock(bo);
>>> +
>>> +	if (ret)
>>> +		KUNIT_FAIL(test, "Unaligned large write failed: %d\n", ret);
>>> +	else
>>> +		verify_access_memory_read(test, buf, 0, 0, size - offset,
>>> +					  "Unaligned large write");
>>> +
>>> +	xe_bo_unpin_map_no_vm(bo);
>>> +free_buf:
>>> +	kvfree(buf);
>>> +}
>>> +
>>>    static int access_memory_test_run_device(struct xe_device *xe)
>>>    {
>>>    	struct kunit *test = kunit_get_current_test();
>>> @@ -1059,6 +1106,9 @@ static int access_memory_test_run_device(struct xe_device *xe)
>>>    
>>>    		kunit_info(test, "Testing tile id %d (random offset)\n", id);
>>>    		access_memory_test_run_tile(xe, tile, test, true);
>>> +
>>> +		kunit_info(test, "Testing tile id %d (unaligned large write)\n", id);
>>> +		access_memory_test_unaligned_large_write(test, tile);
>>>    	}
>>>    
>>>    	return 0;


  reply	other threads:[~2026-10-28 10:07 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
2026-10-27 15:57   ` Matthew Auld
2026-10-27 18:04     ` Mika Kuoppala
2026-10-28 10:07       ` Matthew Auld [this message]
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=bb850cb7-5564-47d5-ad6b-98c8cf8f9aa9@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.com \
    /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.