All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arunpravin Paneer Selvam <arunpravin.paneerselvam@amd.com>
To: Matthew Auld <matthew.auld@intel.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Cc: christian.koenig@amd.com, alexander.deucher@amd.com,
	Anand.Raghavendra@amd.com
Subject: Re: [PATCH v4 1/3] gpu/buddy: restore two-pass clear/dirty guard for range-biased allocation
Date: Mon, 19 Oct 2026 10:20:46 +0530	[thread overview]
Message-ID: <471cd64f-6dd1-4f8a-b446-94423d9d1439@amd.com> (raw)
In-Reply-To: <343cf7b2-6241-4e3c-8b37-2f0ea75c6723@intel.com>



On 10/13/2026 8:36 PM, Matthew Auld wrote:
> Hey,
>
> Yes, going to go through it now. Did you already look over the Sashiko 
> reports:
> https://sashiko.dev/#/patchset/20261009100546.1103622-1-arunpravin.paneerselvam%40amd.com 
>
>
> Are they all false positive? I wanted to hold off reviewing if you 
> were going to re-spin.
I am preparing a patch to address the issues reported by Sashiko.
>
> Also, on the "bugs" tab in Sashiko there was one open buddy issue, 
> which I sent a fix for:
> https://lore.kernel.org/intel-xe/20261006110706.1636971-2-matthew.auld@intel.com/ 
>
>
> Please take a look at that.
Sure. I will also take a look at the buddy fix you sent.

Thanks,
Arun.
>
> On 13/10/2026 15:31, Arunpravin Paneer Selvam wrote:
>> Hi Matthew,
>> Could you please review the v4.
>>
>> Thanks,
>> Arun.
>>
>> On 10/9/2026 3:35 PM, Arunpravin Paneer Selvam wrote:
>>> From: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
>>>
>>> Range-restricted allocations (the visible-VRAM aperture) skip
>>> dirty_steer_window() and reach __alloc_range_bias() with no clear/dirty
>>> eligibility guard, so a dirty allocation freely splits clear extents 
>>> (and
>>> vice versa), interleaving the two classes until no large same-class run
>>> survives and a 4K scanout pin fails with -ENOSPC. Use a two-pass range
>>> search instead: block_incompatible() rejects opposite-class blocks 
>>> in the
>>> strict pass and relaxes only when the strict pass returns -ENOSPC, so a
>>> request still succeeds when only opposite-class space remains. A KUnit
>>> regression test covers the interleaving pattern and fails without the
>>> guard.
>>>
>>> Fixes: 1ad5e807f716 ("gpu/buddy: replace dual-tree/force_merge with 
>>> decoupled dirty tracker")
>>> Assisted-by: LLM
>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>> Cc: Christian König <christian.koenig@amd.com>
>>> Signed-off-by: Arunpravin Paneer Selvam 
>>> <Arunpravin.PaneerSelvam@amd.com>
>>> ---
>>>   drivers/gpu/buddy.c                | 71 
>>> ++++++++++++++----------------
>>>   drivers/gpu/tests/gpu_buddy_test.c | 65 +++++++++++++++++++++++++++
>>>   2 files changed, 99 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/drivers/gpu/buddy.c b/drivers/gpu/buddy.c
>>> index 2f2aaadafe35..6566bad4fef1 100644
>>> --- a/drivers/gpu/buddy.c
>>> +++ b/drivers/gpu/buddy.c
>>> @@ -1240,11 +1240,19 @@ static void __gpu_buddy_undo_splits(struct 
>>> gpu_buddy *mm,
>>>       }
>>>   }
>>> +static bool block_incompatible(struct gpu_buddy_block *block, 
>>> unsigned int flags)
>>> +{
>>> +    bool needs_clear = flags & GPU_BUDDY_CLEAR_ALLOCATION;
>>> +
>>> +    return needs_clear != gpu_buddy_block_is_clear(block);
>>> +}
>>> +
>>>   static struct gpu_buddy_block *
>>>   __alloc_range_bias(struct gpu_buddy *mm,
>>>              u64 start, u64 end,
>>>              unsigned int order,
>>> -           unsigned long flags)
>>> +           unsigned long flags,
>>> +           bool fallback)
>>>   {
>>>       u64 req_size = mm->chunk_size << order;
>>>       struct gpu_buddy_block *block;
>>> @@ -1258,9 +1266,7 @@ __alloc_range_bias(struct gpu_buddy *mm,
>>>        * This range-constrained search hands back the 
>>> highest/right-most
>>>        * address that satisfies the request: the roots are seeded 
>>> high-to-low
>>>        * and the right (higher-address) child is descended first, 
>>> making
>>> -     * top-down the default placement here. A non-top-down clear 
>>> request is
>>> -     * the only exception, where the descent is biased towards 
>>> clear or
>>> -     * clear-containing subtrees to satisfy the clear preference.
>>> +     * top-down the default placement here.
>>>        */
>>>       for (i = mm->n_roots - 1; i >= 0; --i)
>>>           list_add_tail(&mm->roots[i]->tmp_link, &dfs);
>>> @@ -1298,6 +1304,9 @@ __alloc_range_bias(struct gpu_buddy *mm,
>>>                   continue;
>>>           }
>>> +        if (!fallback && block_incompatible(block, flags))
>>> +            continue;
>>> +
>>>           if (contains(start, end, block_start, block_end) &&
>>>               order == gpu_buddy_block_order(block)) {
>>>               /*
>>> @@ -1315,38 +1324,8 @@ __alloc_range_bias(struct gpu_buddy *mm,
>>>                   goto err_undo;
>>>           }
>>> -        /*
>>> -         * Top-down is a strict address-placement policy, so when 
>>> it is
>>> -         * requested we ignore clear steering and simply descend the
>>> -         * right (higher-address) child first. Only a non-top-down 
>>> clear
>>> -         * request biases the descent towards clear/has_clear 
>>> subtrees.
>>> -         */
>>> -        if ((flags & GPU_BUDDY_CLEAR_ALLOCATION) &&
>>> -            !(flags & GPU_BUDDY_TOPDOWN_ALLOCATION)) {
>>> -            struct gpu_buddy_block *prefer;
>>> -
>>> -            if (gpu_buddy_block_is_clear(block->right))
>>> -                prefer = block->right;
>>> -            else if (gpu_buddy_block_is_clear(block->left))
>>> -                prefer = block->left;
>>> -            else if (block->right->has_clear)
>>> -                prefer = block->right;
>>> -            else if (block->left->has_clear)
>>> -                prefer = block->left;
>>> -            else
>>> -                prefer = block->right;
>>> -
>>> -            if (prefer == block->right) {
>>> -                list_add(&block->left->tmp_link, &dfs);
>>> -                list_add(&block->right->tmp_link, &dfs);
>>> -            } else {
>>> -                list_add(&block->right->tmp_link, &dfs);
>>> -                list_add(&block->left->tmp_link, &dfs);
>>> -            }
>>> -        } else {
>>> -            list_add(&block->left->tmp_link, &dfs);
>>> -            list_add(&block->right->tmp_link, &dfs);
>>> -        }
>>> +        list_add(&block->left->tmp_link, &dfs);
>>> +        list_add(&block->right->tmp_link, &dfs);
>>>       } while (1);
>>>       return ERR_PTR(-ENOSPC);
>>> @@ -1361,6 +1340,24 @@ __alloc_range_bias(struct gpu_buddy *mm,
>>>       return ERR_PTR(err);
>>>   }
>>> +static struct gpu_buddy_block *
>>> +__gpu_buddy_alloc_range_bias(struct gpu_buddy *mm,
>>> +                 u64 start, u64 end,
>>> +                 unsigned int order,
>>> +                 unsigned long flags)
>>> +{
>>> +    struct gpu_buddy_block *block;
>>> +    bool fallback = false;
>>> +
>>> +    block = __alloc_range_bias(mm, start, end, order,
>>> +                   flags, fallback);
>>> +    if (IS_ERR(block))
>>> +        return __alloc_range_bias(mm, start, end, order,
>>> +                      flags, !fallback);
>>> +
>>> +    return block;
>>> +}
>>> +
>>>   /* Return the highest-address free block of at least @order. */
>>>   static struct gpu_buddy_block *
>>>   get_maxblock(struct gpu_buddy *mm,
>>> @@ -1924,7 +1921,7 @@ __gpu_buddy_alloc_blocks(struct gpu_buddy *mm,
>>>       if (flags & GPU_BUDDY_RANGE_ALLOCATION) {
>>>           /* Allocate traversing within the range */
>>> -        block = __alloc_range_bias(mm, start, end, order, flags);
>>> +        block = __gpu_buddy_alloc_range_bias(mm, start, end, order, 
>>> flags);
>>>           if (!IS_ERR(block) || !steered)
>>>               return block;
>>> diff --git a/drivers/gpu/tests/gpu_buddy_test.c b/drivers/gpu/tests/ 
>>> gpu_buddy_test.c
>>> index b75d32ca6ca0..3eaa261571bf 100644
>>> --- a/drivers/gpu/tests/gpu_buddy_test.c
>>> +++ b/drivers/gpu/tests/gpu_buddy_test.c
>>> @@ -1597,6 +1597,70 @@ static int gpu_buddy_suite_init(struct 
>>> kunit_suite *suite)
>>>       return 0;
>>>   }
>>> +static void gpu_test_buddy_alloc_range_clear_guard(struct kunit *test)
>>> +{
>>> +    const unsigned long chunk = SZ_1M, mm_size = SZ_4M;
>>> +    struct gpu_buddy_block *block;
>>> +    LIST_HEAD(high_clear_a);
>>> +    LIST_HEAD(high_clear_b);
>>> +    LIST_HEAD(low_dirty);
>>> +    struct gpu_buddy mm;
>>> +    LIST_HEAD(barrier);
>>> +    LIST_HEAD(result);
>>> +
>>> +    KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_init(&mm, mm_size, chunk),
>>> +                   "buddy_init failed\n");
>>> +
>>> +    /*
>>> +     * Lay out a 4 MiB aperture as three regions:
>>> +     *
>>> +     *   [0,  1M)   dirty free
>>> +     *   [1M, 2M)   allocated  (barrier, keeps the two halves un- 
>>> mergeable)
>>> +     *   [2M, 4M)   clear free (one naturally aligned 2 MiB extent)
>>> +     *
>>> +     * A dirty (non-clear) range allocation must take the low dirty 
>>> block
>>> +     * and leave the large clear extent intact. Without the guard the
>>> +     * top-down search cuts the higher clear extent instead and 
>>> returns a
>>> +     * clear block -- the interleaving that fragments the aperture and
>>> +     * ultimately fails a large same-class scanout allocation.
>>> +     */
>>> +    KUNIT_ASSERT_FALSE_MSG(test,
>>> +                   gpu_buddy_alloc_blocks(&mm, 0, chunk, chunk, chunk,
>>> +                              &low_dirty, GPU_BUDDY_RANGE_ALLOCATION),
>>> +                   "alloc [0, 1M) failed\n");
>>> +    KUNIT_ASSERT_FALSE_MSG(test,
>>> +                   gpu_buddy_alloc_blocks(&mm, chunk, 2 * chunk, 
>>> chunk, chunk,
>>> +                              &barrier, GPU_BUDDY_RANGE_ALLOCATION),
>>> +                   "alloc [1M, 2M) failed\n");
>>> +    KUNIT_ASSERT_FALSE_MSG(test,
>>> +                   gpu_buddy_alloc_blocks(&mm, 2 * chunk, 3 * 
>>> chunk, chunk, chunk,
>>> +                              &high_clear_a, 
>>> GPU_BUDDY_RANGE_ALLOCATION),
>>> +                   "alloc [2M, 3M) failed\n");
>>> +    KUNIT_ASSERT_FALSE_MSG(test,
>>> +                   gpu_buddy_alloc_blocks(&mm, 3 * chunk, 4 * 
>>> chunk, chunk, chunk,
>>> +                              &high_clear_b, 
>>> GPU_BUDDY_RANGE_ALLOCATION),
>>> +                   "alloc [3M, 4M) failed\n");
>>> +
>>> +    /* [2M, 4M) coalesces into one aligned clear extent; [0, 1M) 
>>> stays dirty. */
>>> +    gpu_buddy_free_list(&mm, &low_dirty, 0);
>>> +    gpu_buddy_free_list(&mm, &high_clear_a, GPU_BUDDY_CLEARED);
>>> +    gpu_buddy_free_list(&mm, &high_clear_b, GPU_BUDDY_CLEARED);
>>> +
>>> +    KUNIT_ASSERT_FALSE_MSG(test,
>>> +                   gpu_buddy_alloc_blocks(&mm, 0, mm_size, chunk, 
>>> chunk,
>>> +                              &result, GPU_BUDDY_RANGE_ALLOCATION),
>>> +                   "dirty range alloc failed\n");
>>> +
>>> +    block = list_first_entry(&result, struct gpu_buddy_block, link);
>>> +    KUNIT_EXPECT_FALSE_MSG(test, gpu_buddy_block_is_clear(block),
>>> +                   "dirty range alloc cut the clear extent 
>>> (offset=%llx)\n",
>>> +                   gpu_buddy_block_offset(block));
>>> +
>>> +    gpu_buddy_free_list(&mm, &result, 0);
>>> +    gpu_buddy_free_list(&mm, &barrier, 0);
>>> +    gpu_buddy_fini(&mm);
>>> +}
>>> +
>>>   static struct kunit_case gpu_buddy_tests[] = {
>>>       KUNIT_CASE(gpu_test_buddy_alloc_limit),
>>>       KUNIT_CASE(gpu_test_buddy_alloc_optimistic),
>>> @@ -1606,6 +1670,7 @@ static struct kunit_case gpu_buddy_tests[] = {
>>>       KUNIT_CASE(gpu_test_buddy_alloc_clear),
>>>       KUNIT_CASE(gpu_test_buddy_alloc_range),
>>>       KUNIT_CASE(gpu_test_buddy_alloc_range_bias),
>>> +    KUNIT_CASE(gpu_test_buddy_alloc_range_clear_guard),
>>> KUNIT_CASE_SLOW(gpu_test_buddy_fragmentation_performance),
>>> KUNIT_CASE_SLOW(gpu_test_buddy_dirty_tracker_performance),
>>>       KUNIT_CASE(gpu_test_buddy_alloc_exceeds_max_order),
>>>
>>> base-commit: f146c6086b792cb2c6b3ce5106f0cce62e408df8
>>
>


  reply	other threads:[~2026-10-19  4:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 10:05 [PATCH v4 1/3] gpu/buddy: restore two-pass clear/dirty guard for range-biased allocation Arunpravin Paneer Selvam
2026-10-09 10:05 ` [PATCH v4 2/3] gpu/buddy: add range-restricted contiguous allocation fallback Arunpravin Paneer Selvam
2026-10-09 10:23   ` sashiko-bot
2026-10-09 10:05 ` [PATCH v4 3/3] gpu/buddy: search lower orders in contiguous try-harder fallback Arunpravin Paneer Selvam
2026-10-09 10:15 ` ✓ CI.KUnit: success for series starting with [v4,1/3] gpu/buddy: restore two-pass clear/dirty guard for range-biased allocation Patchwork
2026-10-09 10:17 ` [PATCH v4 1/3] " sashiko-bot
2026-10-09 11:13 ` ✓ Xe.CI.BAT: success for series starting with [v4,1/3] " Patchwork
2026-10-09 12:07 ` ✓ i915.CI.BAT: " Patchwork
2026-10-09 13:35 ` ✓ Xe.CI.FULL: " Patchwork
2026-10-09 14:58 ` ✓ i915.CI.Full: " Patchwork
2026-10-13 14:31 ` [PATCH v4 1/3] " Arunpravin Paneer Selvam
2026-10-13 15:06   ` Matthew Auld
2026-10-19  4:50     ` Arunpravin Paneer Selvam [this message]
2026-10-20  6:01       ` Arunpravin Paneer Selvam

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=471cd64f-6dd1-4f8a-b446-94423d9d1439@amd.com \
    --to=arunpravin.paneerselvam@amd.com \
    --cc=Anand.Raghavendra@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@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.