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

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

Patch Review

**Subject:** `[PATCH v4 6/6] drm/xe: Avoid shrinker reclaim from kswapd under fragmentation`

```c
+	if (ttm_bo_shrink_kswap_maybe_fragmented(sc->nid, sc->order))
+		goto out;
```

**Placement concern:** This check is inserted at line 238 in `xe_shrinker_scan`, between the purgeable scan (phase 1) and the backup/writeback scan (phase 2):

```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)
		runtime_pm = xe_shrinker_runtime_pm_get(shrinker, true, 0, can_backup);
```

**This placement is well-chosen.** It allows purgeable BOs to still be freed (those are cheap to reclaim — no writeback needed, just discarded). It only blocks the more expensive backup/writeback path where active GPU working set would be evicted to swap/shmem. This is the right tradeoff: during fragmentation-driven kswapd, purge expendable objects but don't evict active working sets.

**However**, the `goto out` means `sc->nr_scanned` retains the value from the purgeable scan, and the return is `nr_scanned ? freed : SHRINK_STOP`. If the purgeable scan found nothing to scan (`nr_scanned == 0`) and we hit the fragmentation bail-out, we'll return `SHRINK_STOP`, which tells the MM "this shrinker has nothing to offer." That's actually the desired behavior here — if we have nothing purgeable and we're under fragmentation, we genuinely don't want kswapd to keep hammering this shrinker.

**No functional issues. Good integration.**

---

## Summary

The series addresses a real problem with a reasonable layered approach. **Patch 3 is the main concern** — the change from `__GFP_DIRECT_RECLAIM` to `__GFP_RECLAIM` and the broadened condition from `order > beneficial_order` to `order != beneficial_order` are both more aggressive than justified in the commit message, and the commit message itself is inconsistent with the implementation. The remaining patches are solid, with minor documentation and style nits in patches 2 and 4.

---
Generated by Claude Code Patch Reviewer