Claude review: drm/ttm: Issue direct reclaim at beneficial_order

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

Patch Review

**Overall:** This is the most impactful patch in terms of allocation behavior change.

**Key change:**
```c
-	if (beneficial_order && order > beneficial_order)
-		gfp_flags &= ~__GFP_DIRECT_RECLAIM;
+	if (order && beneficial_order && order != beneficial_order)
+		gfp_flags &= ~__GFP_RECLAIM;
```

**Concerns:**

- **`~__GFP_RECLAIM` vs `~__GFP_DIRECT_RECLAIM`:** The old code only suppressed direct reclaim (keeping kswapd wakeup possible). The new code clears `__GFP_RECLAIM` entirely (`__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM`), meaning these allocations won't even wake kswapd. This is a substantial semantic change. The commit message says "issuing direct reclaim or triggering kswap at a lower order than beneficial_order is ineffective" — this is true for the driver, but kswapd serves the entire system, not just this driver. Suppressing kswapd wakeup from TTM allocations could delay legitimate system-wide reclaim. This deserves more justification or at least acknowledgment in the commit message.

- **Orders below beneficial_order:** The old condition was `order > beneficial_order` — only orders *above* the sweet spot lost direct reclaim. The new condition `order != beneficial_order` also covers orders *below* beneficial_order. Combined with the broader `~__GFP_RECLAIM`, this means a TTM order-4 allocation on a system with beneficial_order=9 will now be `__GFP_NORETRY | __GFP_NOWARN | __GFP_THISNODE` with NO reclaim at all. If this allocation fails, TTM falls back to smaller orders, and the order-0 fallback (`if (order)` is false for order 0) will still get full reclaim. But intermediate orders between 1 and beneficial_order-1 also lose all reclaim. Is that intended? The commit message only discusses orders above and at beneficial_order, not below.

- **Interaction with existing `__GFP_NORETRY`:** Note that for `order > 0`, the function already sets `__GFP_NORETRY` at line 161. Combined with clearing `__GFP_RECLAIM`, these allocations become pure "try once, fail fast" — which is probably fine since TTM has its own fallback path, but it's worth calling out.

- **Reviewed-by from Christian Koenig** is reassuring since he understands TTM pool behavior deeply.

---
Generated by Claude Code Patch Reviewer