kernel/git/next/linux-next.git/drivers/gpu/buddy.c, branch master

Merge drm/drm-next into drm-misc-next

2026-09-07T11:44:24+00:00

Backmerging to get drm-misc-next up to v7.3-rc2. Requested for commit 3a2c4d55e32a ("treewide: refresh kmalloc_obj() conversions"). Signed-off-by: Thomas Zimmermann

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

Merge drm/drm-next into drm-misc-next

2026-08-31T07:01:06+00:00

Getting drm-misc-next up to v7.3-rc1. In exynos, there was a conflict in exynos_dbi_bind(). The merge resolves it to the state of commit 3cc8eee9f346 ("drm/exynos: remove dependency on DRM simple helpers"). Signed-off-by: Thomas Zimmermann

gpu/buddy: replace dual-tree/force_merge with decoupled dirty tracker

2026-08-27T12:28:29+00:00

The current buddy allocator maintains separate clear_tree[] and dirty_tree[] rbtrees per order, preventing coalescing between cleared and dirty buddies. Under mixed workloads, this creates a merge barrier: adjacent buddies frequently end up split across trees, forcing reliance on __force_merge() during allocation. __force_merge() performs an O(N x max_order) scan under the VRAM manager lock, leading to allocation stalls and failures for large contiguous requests even when sufficient total free memory is available. Solution Replace the dual-tree design with: - A single free_tree[order] rbtree for dirty and mixed free blocks (fully cleared free blocks float outside this tree) - A lightweight out-of-band dirty tracker (gpu_dirty_tracker) Fully cleared free blocks are tracked outside the buddy trees using an augmented interval rbtree, enabling O(log E) lookup of the largest cleared extents. Buddy coalescing is now unconditional in __gpu_buddy_free(), regardless of clear/dirty state. This removes the merge barrier and eliminates the need for __force_merge(). Benefits - Correct high-order allocations after mixed clear/dirty workloads - Elimination of O(N x max_order) merge cost from the allocation path - O(log E) cleared-extent lookup replacing O(N) scans - Predictable allocation latency under fragmentation - Reduced complexity with a single tree per order Test: dEQP-VK.memory.allocation.basic.size_8KiB.reverse.count_4000 Below data is from /sys/kernel/debug/dri/1/amdgpu_vram_mm: Base (dual-tree), before VKCTS test: order- 6 free: 6 MiB, blocks: 26 order- 5 free: 1 MiB, blocks: 15 order- 4 free: 960 KiB, blocks: 15 order- 3 free: 5 MiB, blocks: 171 order- 2 free: 2 MiB, blocks: 176 order- 1 free: 1 MiB, blocks: 165 order- 0 free: 16 KiB, blocks: 4 Base (dual-tree), after VKCTS test: order- 6 free: 768 KiB, blocks: 3 order- 5 free: 499 MiB, blocks: 3999 order- 4 free: 250 MiB, blocks: 4001 order- 3 free: 129 MiB, blocks: 4157 order- 2 free: 65 MiB, blocks: 4161 order- 1 free: 63 MiB, blocks: 8138 order- 0 free: 20 KiB, blocks: 5 Dirty tracker, before VKCTS test: order- 6 free: 4 MiB, blocks: 19 order- 5 free: 2 MiB, blocks: 18 order- 4 free: 704 KiB, blocks: 11 order- 3 free: 5 MiB, blocks: 168 order- 2 free: 2 MiB, blocks: 174 order- 1 free: 1 MiB, blocks: 167 order- 0 free: 32 KiB, blocks: 8 Dirty tracker, after VKCTS test: order- 6 free: 4 MiB, blocks: 19 order- 5 free: 2 MiB, blocks: 18 order- 4 free: 704 KiB, blocks: 11 order- 3 free: 5 MiB, blocks: 168 order- 2 free: 2 MiB, blocks: 174 order- 1 free: 1 MiB, blocks: 167 order- 0 free: 28 KiB, blocks: 7 v2: - Code-style cleanup and minor refactoring - Renamed locals for clarity v3: - Keep cleared blocks inside free_tree[] instead of floating them. - Add subtree_has_dirty rbtree augment for O(log N) dirty-first walk. v4: - Fixed checkpatch warnings. - Optimized gpu_buddy_reset_clear() to a single post-order walk that flips block headers and recomputes the rbtree augment in one pass. - Propagate subtree_max_size top-down in insert_extent() so ancestors are not left with stale values on no-rotation inserts. (sashiko) - Drop the whole extent in gpu_dirty_tracker_mark_dirty() when the inside-split allocation fails, avoiding a stale clear claim. (sashiko) - Make gpu_dirty_tracker_find() alignment-aware and fall back to the dirty tree on steered failure to avoid spurious -ENOSPC. (sashiko) v5: - Track dirty extents instead of cleared ones: steer dirty allocs onto tracked dirty windows and pick clear allocs via a free-tree augment, avoiding clear-memory wastage by keeping cleared free blocks untouched during dirty allocation. v6: - Make __alloc_range_bias() return the highest/right-most address by default, establishing top-down as the intended placement for range-biased allocations. - Honour GPU_BUDDY_CLEAR_ALLOCATION in __alloc_range_bias() by steering the descent towards clear subtrees for non-top-down clear requests. (sashiko) - Skip dirty-tracker steering for offset-aligned requests so they keep their min_block_size alignment. (sashiko) - sashiko reported that the __GFP_NOFAIL dirty-extent allocations on the free path could deadlock during memory reclaim, since that is a GFP_KERNEL allocation on the free path; move to a per-tracker mempool so extent nodes are guaranteed without __GFP_NOFAIL. (sashiko) - Derive each free block's clear/dirty class from the blocks already in hand on split, free, alloc, trim and init instead of querying the dirty tracker, removing the tracker lookups from the hot paths. v7: - Preserve mixed-block clear state in __gpu_buddy_free() when a mixed split child is re-merged after an undone split. (sashiko) - Prefer a fully-clear block over a mixed one of the same order via a single ordered clear-state max augment on free_tree[]. v8: - Coalesce contiguous dirty blocks in __gpu_buddy_free_list() into one dirty extent update instead of one mark_dirty() per block. (Matthew) v9: - Reset has_clear on allocation so a mixed block taken whole and later freed fully dirty is not re-tracked as mixed. (sashiko) v10: - Use a plain slab allocation for dirty extents; skip and log once on failure. (Matthew) - Assert a non-zero size in the dirty-tracker range helpers. (Matthew) - Drop the cached clear_avail member; derive it on demand. (Matthew) - Collapse the two dirty branches of gpu_buddy_reset_clear(). (Matthew) - Move the gpu_block_state enum above the gpu_buddy_block kernel-doc so the doc directly precedes its struct. (Matthew) - Mark the gpu_dirty_tracker struct private. (Matthew) - Preserve a block's clear state on non-clear allocation instead of force-dirtying it. (Matthew) - Drop the redundant header clear in gpu_buddy_block_trim(). (Matthew) v11: - Assert the manager lock is held in gpu_buddy_clear_avail(). (Matthew) Assisted-by: Claude:claude-opus-4-8 Cc: Matthew Auld Cc: Christian König Signed-off-by: Arunpravin Paneer Selvam Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260825172432.80355-1-Arunpravin.PaneerSelvam@amd.com

BackMerge tag 'v7.2' into drm-next

2026-08-20T00:58:44+00:00

Linux 7.2 There was a lot of conflicts this round between fixes and next, and I'd like to get the merge resolutions that we have in drm-tip. Signed-off-by: Dave Airlie

drm/gpu: Add gpu_buddy_allocated_addr_to_block helper

2026-08-06T11:28:54+00:00

Add helper with primary purpose is to efficiently trace a specific physical memory address back to its corresponding TTM buffer object. v3: - use mm->chunk_size minimum allocation granularity (Arun) v2: - %s/gpu_buddy_addr_to_block/gpu_buddy_allocated_addr_to_block(MattA) - remove clear->avail and split nodes check(MattA) - Adapt lockdep(MattB) Signed-off-by: Tejas Upadhyay Cc: Arunpravin Paneer Selvam Cc: dri-devel@lists.freedesktop.org Reviewed-by: Arunpravin Paneer Selvam Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260806053624.3215216-5-tejas.upadhyay@intel.com

gpu/buddy: bail out of try_harder when alignment cannot be honoured

2026-07-09T13:19:49+00:00

The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König Cc: Matthew Auld Cc: Christian König Cc: Timur Kristóf Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld Tested-by: John Olender Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com

gpu/buddy: Track per-order used blocks with a scoreboard

2026-05-29T11:44:01+00:00

Extend the scoreboard approach from the previous commit to used blocks, so drm_buddy_print() can report per-order allocation pressure in O(1). Unlike free blocks, an allocated block can leave the allocated state through mark_free() (normal free and gpu_buddy_block_trim()) or be consumed directly by gpu_block_free() during coalescing. Both sites are guarded by gpu_buddy_block_is_allocated() and paired with the increment in mark_allocated(). v3: - Assert scoreboard is empty at fini(), as sanity check (Matthew Auld) v2: - Update after fix for use-after-free in split_block() call sites - Change goto label to out_free_used_scoreboard for clarity - Make drm_buddy_print() and gpu_buddy_print() symmetric for used and free Assisted-by: GitHub Copilot:claude-sonnet-4.6 Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-6-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Track per-order free blocks with a scoreboard

2026-05-29T11:44:00+00:00

Reporting per-order free block counts in drm_buddy_print() currently requires walking all rbtrees, which is O(n) over the total number of free blocks and holds the allocator lock for the duration. This becomes expensive on large VRAM heaps with many small free fragments. Maintain a free_scoreboard[] array indexed by order instead, so that the count for any order is always available in O(1). The scoreboard is kept accurate by hooking into the four places where a block's free state changes: mark_free(), mark_allocated(), mark_split(), and the sites in __gpu_buddy_free(), __force_merge(), and the four err_undo paths that call rbtree_remove() directly on free blocks without going through mark_*(). The print functions are simplified as a result: the rbtree traversal is replaced by a direct array lookup. v3: Update after introducing __gpu_buddy_undo_splits() helper v2: Update after fix for use-after-free in split_block() call sites Assisted-by: GitHub Copilot:claude-sonnet-4.6 Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-5-francois.dugast@intel.com Signed-off-by: Francois Dugast

gpu/buddy: Introduce __gpu_buddy_undo_splits() helper

2026-05-29T11:44:00+00:00

The pattern of merging a block back with its buddy on error paths is duplicated across multiple locations. Extract it into a __gpu_buddy_undo_splits() helper to avoid repetition and prepare for future changes. Suggested-by: Matthew Auld Reviewed-by: Matthew Auld Link: https://lore.kernel.org/r/20260522092600.32818-4-francois.dugast@intel.com Signed-off-by: Francois Dugast