Claude review: drm/xe: Avoid shrinker reclaim from kswapd under fragmentation

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

Patch Review

**Overall:** The payoff patch that uses the helper from patch 4 in the Xe shrinker.

```c
 	if (nr_scanned >= nr_to_scan || !can_backup)
 		goto out;

+	if (ttm_bo_shrink_kswap_maybe_fragmented(sc->nid, sc->order))
+		goto out;
+
 	/* If we didn't wake before, try to do it now if needed. */
 	if (!runtime_pm)
```

**Concerns:**

- **Placement is significant:** The check is placed *after* purgeable object scanning (lines 228-233) but *before* the non-purgeable (active BO backup/eviction) walk (lines 243-248). This means purgeable objects will still be reclaimed under fragmentation, but active BOs won't be evicted. This is exactly the right design — purgeable objects are cheap to re-create, while evicting active BOs triggers the expensive rebind loop described in the cover letter.

- **Return value:** When this `goto out` triggers, the function returns either `freed` (if something was purged) or `SHRINK_STOP` (if `nr_scanned == 0`). Returning `SHRINK_STOP` tells the mm core to stop invoking this shrinker. This seems appropriate — the shrinker is saying "I can't help, don't call me again for this reclaim cycle."

- **No tracing/debugging:** When the shrinker bails out due to fragmentation, there's no trace event or debug print. For a heuristic that skips potentially useful reclaim, it would be valuable to have a trace point (even if behind `CONFIG_DEBUG` or xe's own debug flags) so developers can observe when this kicks in. Not a blocker, but worth considering.

- **Missing Reviewed-by:** Unlike patches 3 and 5, this patch has no Reviewed-by tag. Given it directly changes Xe shrinker behavior, getting Thomas Hellström's or Matthew Auld's review would strengthen it.

---

**Summary:** The series is well-structured and addresses a real problem with measurable results. The main areas for scrutiny are: (1) the `~__GFP_RECLAIM` change in patch 3 which suppresses kswapd wakeup — this is a stronger change than the commit message suggests, (2) the mm core changes (patches 1-2) need mm maintainer buy-in, and (3) the fragmentation heuristic is intentionally coarse which is fine for a first iteration but could benefit from being compared against the beneficial_order rather than just `order != 0`.

---
Generated by Claude Code Patch Reviewer