Claude review: mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation

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

Overall Series Review

Subject: mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation
Author: Matthew Brost <matthew.brost@intel.com>
Patches: 7
Reviewed: 2026-05-05T10:13:40.738286

---

This is a well-motivated 6-patch series addressing a real and measurable performance regression on Xe GPU systems under memory fragmentation. The problem statement is clear: kswapd-driven shrinker calls evict GPU BOs even when the system has ample free memory but is fragmented at high orders, leading to a pathological evict-rebind loop.

The approach is layered sensibly: (1) plumb allocation order through to shrinkers, (2) add a fragmentation heuristic, (3) adjust TTM pool allocation GFP flags, (4) add a TTM helper to detect fragmentation under kswapd, (5-6) wire it into Xe. The series has appropriate Reviewed-by tags from Christian Koenig (TTM maintainer) and Andi Shyti on the TTM/Xe patches.

**Key concerns:**

1. **Patch 1 (mm core):** Adding `order` to `shrink_control` is a reasonable approach, but this is core mm infrastructure — it needs mm maintainer buy-in (Andrew Morton, etc.). The type choice of `s8` for `order` matches `scan_control.order` which is good for consistency.

2. **Patch 3 (TTM GFP change):** The semantic change from `~__GFP_DIRECT_RECLAIM` to `~__GFP_RECLAIM` is significant — it also suppresses kswapd wakeup. The condition change from `order > beneficial_order` to `order != beneficial_order` means orders *below* beneficial_order also lose reclaim, which needs careful thought.

3. **Patch 2 (fragmentation heuristic):** The `2x high watermark` heuristic is intentionally coarse. It could produce false positives on systems with legitimately high watermarks. Placing it in `vmstat.h` as an inline means it's part of the mm public API, which needs mm maintainer agreement.

---

---
Generated by Claude Code Patch Reviewer