From: "Yadav, Sanjay Kumar" <sanjay.kumar.yadav@intel.com>
To: <sashiko-reviews@lists.linux.dev>, <dri-devel@lists.freedesktop.org>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v2 2/2] gpu/tests/buddy: Add range-bias pruning and free-order tracking tests
Date: Thu, 22 Oct 2026 10:11:43 +0530 [thread overview]
Message-ID: <aa357cbe-fcfa-41f5-ae82-fdc8cd79f495@intel.com> (raw)
In-Reply-To: <sashiko-outbox-180522@kernel.org>
On 21-10-2026 22:54, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] gpu/tests/buddy: 64-bit division in gpu_test_buddy_range_bias_pruning()
> --
>
> commit c218b91af95d861d31913d5c9b3ba0681e319523
> Author: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
>
> gpu/tests/buddy: Add range-bias pruning and free-order tracking tests
>
> This commit adds KUnit tests in drivers/gpu/tests/gpu_buddy_test.c to verify
> range-bias subtree pruning and subtree_max_free_order tracking across block
> allocation, splitting, coalescing, and trimming operations.
>
>> diff --git a/drivers/gpu/tests/gpu_buddy_test.c b/drivers/gpu/tests/gpu_buddy_test.c
>> index b75d32ca6ca0a..4c7e823d57892 100644
>> --- a/drivers/gpu/tests/gpu_buddy_test.c
>> +++ b/drivers/gpu/tests/gpu_buddy_test.c
>> @@ -1586,6 +1586,311 @@ static void gpu_test_buddy_addr_to_block(struct kunit *test)
>> gpu_buddy_fini(&mm);
>> }
>>
> [ ... ]
>> +static void gpu_test_buddy_range_bias_pruning(struct kunit *test)
>> +{
>> + const u64 mm_size = SZ_512M, range_end = SZ_128M, chunk = SZ_4K;
>> + const unsigned int nr = range_end / chunk, window = 1024;
>> + const u64 holes[] = { 0, range_end / 2 + 3 * chunk };
>> + struct gpu_buddy_block *block, *hidden;
>> + u64 first_ns = 0, last_ns = 0;
>> + unsigned int i, misplaced = 0;
>> + LIST_HEAD(allocated);
>> + struct gpu_buddy mm;
>> + LIST_HEAD(tmp);
>> + int err;
> [ ... ]
>> + for (i = 0; i < nr; i++) {
>> + ktime_t start = ktime_get();
>> + u64 elapsed;
>> +
>> + err = gpu_buddy_alloc_blocks(&mm, 0, range_end, chunk, chunk,
>> + &allocated, GPU_BUDDY_RANGE_ALLOCATION);
>> + elapsed = ktime_to_ns(ktime_sub(ktime_get(), start));
>> + KUNIT_ASSERT_EQ_MSG(test, err, 0, "range alloc %u failed\n", i);
>> +
>> + if (i < window)
>> + first_ns += elapsed;
>> + else if (i >= nr - window)
>> + last_ns += elapsed;
>> +
>> + block = list_last_entry(&allocated, struct gpu_buddy_block, link);
>> + if (gpu_buddy_block_offset(block) != range_end - (u64)(i + 1) * chunk)
>> + misplaced++;
>> + }
>> +
>> + kunit_info(test, "first %u range allocs: %llu us, last %u: %llu us\n",
>> + window, first_ns / NSEC_PER_USEC, window, last_ns / NSEC_PER_USEC);
> [Severity: Low]
> In gpu_test_buddy_range_bias_pruning() in drivers/gpu/tests/gpu_buddy_test.c,
> first_ns and last_ns are u64 variables that accumulate runtime nanosecond
> durations. On 32-bit architectures with CONFIG_GPU_BUDDY_KUNIT_TEST enabled,
> won't dividing them directly with the / operator by NSEC_PER_USEC emit calls
> to __udivdi3 or __aeabi_uldivmod and cause a link failure?
>
> Should this use div_u64() (or ktime_to_us()) instead?
Yes, this matches the kernel test robot’s __aeabi_uldivmod failure on
32-bit ARM.
I reproduced it locally on 32bit compiler and confirmed that replacing
the direct u64 divisions with div_u64() fixes the issue.
>
> [ ... ]
>
next prev parent reply other threads:[~2026-10-22 4:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 17:09 [PATCH v2 0/2] gpu/buddy: Fix quadratic cost of range-biased allocation Sanjay Yadav
2026-10-21 17:09 ` [PATCH v2 1/2] gpu/buddy: Prune exhausted subtrees in " Sanjay Yadav
2026-10-21 17:09 ` [PATCH v2 2/2] gpu/tests/buddy: Add range-bias pruning and free-order tracking tests Sanjay Yadav
2026-10-21 17:24 ` sashiko-bot
2026-10-22 4:41 ` Yadav, Sanjay Kumar [this message]
2026-10-21 17:25 ` ✓ CI.KUnit: success for gpu/buddy: Fix quadratic cost of range-biased allocation (rev3) Patchwork
2026-10-21 18:01 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-21 20:57 ` ✓ 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=aa357cbe-fcfa-41f5-ae82-fdc8cd79f495@intel.com \
--to=sanjay.kumar.yadav@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.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.