From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: cgroup/dmem: implement dmem.high soft limit via prioritized eviction
Date: Thu, 04 Jun 2026 15:52:23 +1000 [thread overview]
Message-ID: <review-patch1-20260530-feature-dmem-high-v4-1-ee7c6ec1c8da@gmail.com> (raw)
In-Reply-To: <20260530-feature-dmem-high-v4-1-ee7c6ec1c8da@gmail.com>
Patch Review
#### Bug: Pass 2 uses blocking lock instead of trylock
In `ttm_bo_evict_alloc()`, Pass 1 sets `trylock_only = false` for the blocking high-priority pass, but this is never restored before Pass 2:
```c
+ evict_walk.walk.arg.trylock_only = false;
+ evict_walk.try_high = true;
lret = ttm_lru_walk_for_evict(&evict_walk.walk, bdev, man, 1);
+ evict_walk.try_high = false;
+ if (lret)
+ goto out;
+
+ /*
+ * Pass 2 (trylock): Evict BOs above the effective low watermark.
+ */
lret = ttm_lru_walk_for_evict(&evict_walk.walk, bdev, man, 1);
```
The comment says "Pass 2 (trylock)" but `trylock_only` is still `false` from Pass 1. The original code had `trylock_only = true` here. This changes the locking behavior for the standard eviction pass — it will now take blocking locks on BOs that it shouldn't, potentially causing excessive blocking or deadlocks. A `evict_walk.walk.arg.trylock_only = true;` is needed before Pass 2.
#### Bug: try_high path skips limit_pool/test_pool hierarchy check
The existing `dmem_cgroup_state_evict_valuable()` verifies that `test_pool` is a descendant of `limit_pool` before allowing eviction:
```c
for (pool = test_pool; pool && limit_pool != pool; pool = pool_parent(pool))
{}
if (!pool)
return false;
```
The new `try_high` path bypasses this entirely. When `limit_pool != test_pool`, the code goes straight into the ancestor high-limit walk without verifying the hierarchy relationship:
```c
+ if (try_high) {
+ if (limit_pool == test_pool)
+ return used > READ_ONCE(ctest->high);
+
+ {
+ struct page_counter *c;
+ if (used <= READ_ONCE(ctest->high)) {
+ for (c = ctest->parent; c; c = c->parent) {
+ if (page_counter_read(c) >
+ READ_ONCE(c->high))
+ break;
+ }
+ if (!c)
+ return false;
+ }
+ }
```
This means if cgroup A hits its `max` limit and triggers eviction, a BO from completely unrelated cgroup B can be evicted if B (or any of B's ancestors) exceeds its high limit. This is unfair — A's over-allocation shouldn't cause eviction from an unrelated cgroup tree.
Furthermore, when the hierarchy isn't verified, the subsequent call to `dmem_cgroup_calculate_protection(limit_pool, test_pool)` iterates `limit_pool`'s descendants looking for `test_pool`, won't find it, and returns without updating `test_pool->cnt.emin`. The `used > min` check then reads a stale `emin` value.
If the intent is to only evict over-high descendants of the limit-hitting cgroup, the hierarchy check from the non-try_high path should be included. If the intent is truly global (evict any over-high BO regardless of hierarchy), that's a design decision that should be explicitly documented, and the `dmem_cgroup_calculate_protection` call needs to use the correct root for test_pool.
#### Style: Bare block for variable declaration
```c
+ {
+ struct page_counter *c;
+ ...
+ }
```
This nested scope block is unusual for kernel style. The variable `c` could be declared at the top of the `if (try_high)` block or at function scope alongside the existing local variables.
#### Commit message typo
The commit message says "above-elow" in two places — should be "above-low":
> Pass 2 falls back to the standard above-elow trylock eviction.
#### Minor: cgroupfs plumbing looks correct
The `set_resource_high()`, `get_resource_high()`, `reset_all_resource_limits()` addition, and the `cftype` file registration all follow the established pattern for `min`/`low`/`max` correctly. The `get_resource_high(NULL)` returning `PAGE_COUNTER_MAX` (matching `get_resource_max()` behavior) is the right default.
#### Missing: No documentation update
The kernel typically documents cgroup control files in `Documentation/admin-guide/cgroup-v2.rst`. A new user-facing control file like `dmem.high` should have corresponding documentation describing its semantics, default value, and interaction with `dmem.max`, `dmem.low`, and `dmem.min`.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-06-04 5:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 7:35 [PATCH v4] cgroup/dmem: implement dmem.high soft limit via prioritized eviction Qiliang Yuan
2026-06-04 5:52 ` Claude review: " Claude Code Review Bot
2026-06-04 5:52 ` Claude Code Review Bot [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-05-31 8:45 [PATCH v5] " Qiliang Yuan
2026-06-04 5:03 ` Claude review: " Claude Code Review Bot
2026-06-04 5:03 ` Claude Code Review Bot
2026-05-31 9:52 [PATCH v6] " Qiliang Yuan
2026-06-04 4:56 ` Claude review: " Claude Code Review Bot
2026-06-04 4:56 ` Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260530-feature-dmem-high-v4-1-ee7c6ec1c8da@gmail.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox