From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/panthor: Add freed_sz parameter to reclaim_priv_bos Date: Thu, 07 May 2026 13:42:51 +1000 Message-ID: In-Reply-To: <20260506-panthor-explicit-reclaim-v1-1-44f82ac147ce@collabora.com> References: <20260506-panthor-explicit-reclaim-v1-0-44f82ac147ce@collabora.com> <20260506-panthor-explicit-reclaim-v1-1-44f82ac147ce@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review **Verdict: Looks reasonable, minor concern.** The change adds an optional `size_t *freed_sz` out-parameter to `panthor_mmu_reclaim_priv_bos()`, which accumulates `panthor_vm_page_size(vm) * newly_freed` across VMs. The existing caller in `panthor_gem_shrinker_scan` passes `NULL`, preserving existing behavior. The implementation is clean: ```c newly_freed = drm_gem_lru_scan(&vm->reclaim.lru, nr_to_scan - freed, remaining, shrink, NULL); if (freed_sz) *freed_sz += panthor_vm_page_size(vm) * newly_freed; freed += newly_freed; ``` **Minor note:** `drm_gem_lru_scan` returns the number of *objects* freed, not pages. The calculation `panthor_vm_page_size(vm) * newly_freed` assumes each object is exactly one page. If multi-page BOs are ever on the reclaim LRU, this underreports the actual freed size. The commit message says "the page size is a per-VM property" which implies these are single-page objects, but a comment or assertion documenting this assumption would help. The `freed_sz` is currently only consumed by `drm_dbg` in patch 3, so the practical impact of any inaccuracy is low. --- Generated by Claude Code Patch Reviewer