From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: gpu/buddy: Track per-order used blocks with a scoreboard Date: Mon, 25 May 2026 19:06:38 +1000 Message-ID: In-Reply-To: <20260522092600.32818-6-francois.dugast@intel.com> References: <20260522092600.32818-1-francois.dugast@intel.com> <20260522092600.32818-6-francois.dugast@intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Correctness: The used scoreboard maintenance is mostly correct, with one = item worth double-checking.** Increment site: - `mark_allocated()` =E2=80=94 block enters allocated state Decrement sites: - `mark_free()` =E2=80=94 guarded by `gpu_buddy_block_is_allocated(block)`,= which is correct because `mark_free` is also called on SPLIT blocks (durin= g the coalescing path in `__gpu_buddy_free` at the bottom: `mark_free(mm, b= lock)`), and those should not decrement the used scoreboard. - `__gpu_buddy_free()` coalescing loop =E2=80=94 guarded by `gpu_buddy_bloc= k_is_allocated(block)`, handling the case where an allocated block is consu= med during coalescing. ```c + if (gpu_buddy_block_is_allocated(block)) + mm->used_scoreboard[gpu_buddy_block_order(block)]--; + gpu_block_free(mm, block); ``` **Question about the coalescing path in `__gpu_buddy_free()`:** The coalesc= ing loop at line ~277 walks up the tree merging block+buddy pairs. The `blo= ck` variable in the loop is the block being freed. On entry to `__gpu_buddy= _free`, is `block` ever in the ALLOCATED state? Looking at the callers: - `mark_free` is called *after* `__gpu_buddy_free` returns (at the bottom o= f the function) - `__gpu_buddy_undo_splits` calls it on a FREE block - `gpu_buddy_free_list_internal` calls `mark_free` then `__gpu_buddy_free` = =E2=80=94 wait, no, it calls `__gpu_buddy_free` which internally calls `mar= k_free` at the end. Actually, looking more carefully at `__gpu_buddy_free`, the block enters as= whatever state it is (the callers should have already ensured appropriate = state), and the loop checks if `buddy` is free. The `block` at each iterati= on is the current node walking up the tree. On the first iteration, the blo= ck could indeed be allocated (if called from a path that hasn't marked it f= ree yet). But looking at all callers of `__gpu_buddy_free`: 1. `__gpu_buddy_undo_splits` =E2=80=94 block is FREE 2. `gpu_buddy_free_list_internal` via `__gpu_buddy_free` =E2=80=94 the bloc= k state depends on the caller Actually, re-reading `__gpu_buddy_free` more carefully: it first does a coa= lescing loop, then calls `mark_free(mm, block)`. The block entering the fun= ction may be in ALLOCATED state (from a direct free path). So the guard `if= (gpu_buddy_block_is_allocated(block))` in the coalescing loop is correct = =E2=80=94 it handles the case where an allocated block is being freed and i= ts buddy is also free, so they merge without going through `mark_free` firs= t. The `gpu_buddy_fini` assertion is a good addition: ```c for (i =3D 0; i <=3D mm->max_order; ++i) gpu_buddy_assert(!mm->used_scoreboard[i]); ``` **The print format change** from `free < SZ_1M` to `block_size < SZ_1M` is = a sensible improvement =E2=80=94 it makes the KiB/MiB display consistent pe= r order rather than per count, so zero-block orders still display in the ri= ght unit. This changes output format for all consumers of `drm_buddy_print`= / `gpu_buddy_print`, but that's debugfs-only so it should be fine. **Minor style observation:** The used_scoreboard comment block in `gpu_budd= y.h` is quite verbose (6 lines), which is fine for kernel code documenting = a non-obvious invariant. No blocking issues found. The series is well-constructed and the scoreboard= bookkeeping appears correct across all state transitions. --- Generated by Claude Code Patch Reviewer