Claude review: Add reclaim to the dmem cgroup controller

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: Add reclaim to the dmem cgroup controller
Author: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
Patches: 6
Reviewed: 2026-05-16T14:48:42.283985

---

This is a well-structured v3 series from Thomas Hellström that adds synchronous reclaim to the dmem cgroup controller, enabling `dmem.max` to be lowered below current VRAM usage without silently failing. The approach is sound: set the new limit immediately (to block concurrent allocations), then invoke a driver-provided reclaim callback to evict memory. The series decomposes cleanly into a bugfix (patch 1), the core cgroup infrastructure (patch 2), the TTM integration layer (patch 3), and two driver wiring patches (4-5).

The synchronization design using `unregister_sem` (rwsem) to protect reclaim callbacks against concurrent unregistration is well thought out and addresses the v2 feedback from Sashiko-bot. The bounded retry loop with signal handling mirrors `memory.max` semantics from the memory cgroup controller, which is a sensible design choice.

Key concerns:
- The `sleeping_lock` locking mode in patch 3 deliberately forgoes WW deadlock detection. The commit message acknowledges this ("should sooner than later be converted to full WW transactions"). This is acceptable for the admin-initiated cgroup write path, but should be tracked as future work.
- The change from `page_counter_set_max()` to raw `xchg()` in patch 2 is a deliberate semantic change that should perhaps be called out more explicitly in the commit message.

Overall: **Looks good with minor comments below.**

---
Generated by Claude Code Patch Reviewer