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

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

Patch Review

This patch changes the reclaim behavior in `ttm_pool_alloc_page()` for non-beneficial orders.

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

There are two distinct changes here that should be clearly called out:

**1. Condition broadened from `order > beneficial_order` to `order != beneficial_order`:**
The old code only disabled reclaim for orders *above* beneficial_order. The new code also disables reclaim for orders *below* beneficial_order (e.g., orders 1-8 when beneficial_order is 9). The rationale in the commit message — "issuing direct reclaim or triggering kswap at a lower order than beneficial_order is ineffective, since the driver does not benefit from reclaiming lower-order pages" — is correct but understates the significance. This is a meaningful behavioral change for the entire fallback path.

Looking at the allocation loop in `__ttm_pool_alloc()` (ttm_pool.c:786-829), when order-9 allocation fails, the allocator falls back through orders 8, 7, ... 1, 0. Under the old code, these fallback orders would still trigger reclaim. Under the new code, only order 0 retains reclaim. This is correct in the fragmentation scenario (plenty of free pages, just not contiguous), but worth verifying that it doesn't hurt the genuine-memory-pressure scenario where even order-0 allocations are tight.

In the genuine pressure case: order 9 with `__GFP_NORETRY` would attempt limited reclaim and fail, orders 8-1 would fail immediately (no reclaim), and order 0 would succeed with full reclaim (no `__GFP_NORETRY`, full `__GFP_RECLAIM`). This seems acceptable since order-0 is the ultimate fallback and handles true pressure.

**2. Flag change from `~__GFP_DIRECT_RECLAIM` to `~__GFP_RECLAIM`:**
`__GFP_RECLAIM` is `__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM` (gfp_types.h:259). The old code only disabled synchronous direct reclaim but still allowed waking kswapd. The new code disables *both*. This is more aggressive — non-beneficial-order allocations won't even wake kswapd. The commit message says "direct reclaim should only be issued with __GFP_NORETRY at exactly beneficial_order" but doesn't explicitly mention that kswapd wakeup is also now suppressed for all non-beneficial orders.

**Suggestion:** The commit message should explicitly call out both changes: (a) reclaim is now disabled for orders *below* beneficial_order (not just above), and (b) kswapd wakeup is also suppressed (not just direct reclaim). These are individually defensible but together represent a substantially more aggressive policy than the old code.

**Minor nit:** The existing comment above this code says "device tolds us" — pre-existing typo, but if you're touching adjacent lines, consider fixing to "device told us".

---
Generated by Claude Code Patch Reviewer