public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/ttm: Hook up a cgroup-aware reclaim callback for the dmem controller
Date: Sat, 16 May 2026 14:04:00 +1000	[thread overview]
Message-ID: <review-patch3-20260512082406.44470-4-thomas.hellstrom@linux.intel.com> (raw)
In-Reply-To: <20260512082406.44470-4-thomas.hellstrom@linux.intel.com>

Patch Review

**Verdict: Good. The TTM integration is solid.**

**NULL place handling in `ttm_bo_evict_cb`:**

```c
+	/*
+	 * evict_walk->place is NULL in cgroup drain mode.  Drivers'
+	 * eviction_valuable() callbacks must handle a NULL place, treating it
+	 * as "any placement": the TTM base implementation already does so via
+	 * ttm_resource_intersects().
+	 */
 	if (bo->pin_count || !bo->bdev->funcs->eviction_valuable(bo, evict_walk->place))
```

I verified that `ttm_resource_intersects()` returns `true` for NULL place, so the base `ttm_bo_eviction_valuable()` correctly treats NULL as "any placement." The xe driver's `xe_bo_eviction_valuable()` calls the base first, so it's also safe. The amdgpu driver is handled in patch 5.

However, the comment says "Drivers' eviction_valuable() callbacks **must** handle a NULL place" but there's no compile-time or runtime enforcement. Any out-of-tree or future driver that dereferences `place` without a NULL check would crash. A comment in the `eviction_valuable` callback documentation (`struct ttm_device_funcs`) would be valuable to prevent future regressions.

**`bo_size` capture:**

```c
+	s64 bo_size = bo->base.size;
```

This correctly captures the GEM object size before eviction may clear the resource. Note that `bo->base.size` is the GEM size, not the VRAM allocation size (which could differ for padded allocations). For progress tracking this is fine since the actual cgroup accounting uses `page_counter_read()`.

**`sleeping_lock` flag:**

```c
+	/**
+	 * @sleeping_lock: Use sleeping locks even with %NULL @ticket.
+	 * @trylock_only has precedence over this field.
+	 */
+	bool sleeping_lock;
```

The change in `ttm_bo_util.c` correctly allows the `ttm_lru_walk_ticketlock` path when `sleeping_lock` is true and no WW ticket is present:

```c
-		else if (!arg->ticket || arg->ctx->no_wait_gpu || arg->trylock_only)
+		else if ((!arg->ticket && !arg->sleeping_lock) || arg->ctx->no_wait_gpu ||
+			 arg->trylock_only)
```

This is correct: without this, the cgroup reclaim path (which has no WW ticket) would only trylock and skip contended BOs, potentially making no progress. The comment in the patch about "sooner than later be converted to full WW transactions" is noted.

**`ttm_resource_manager_set_dmem_region` defensive check:**

```c
+	if (!IS_ERR_OR_NULL(region)) {
+		man->cg = region;
+		dmem_cgroup_region_set_reclaim(region, ...);
+	}
```

The `IS_ERR_OR_NULL` check is defensive since callers already validate, but it prevents storing error pointers (the v3 bug). Reasonable.

---

---
Generated by Claude Code Patch Reviewer

  reply	other threads:[~2026-05-16  4:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12  8:24 [PATCH v4 0/5] Add reclaim to the dmem cgroup controller Thomas Hellström
2026-05-12  8:24 ` [PATCH v4 1/5] drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() Thomas Hellström
2026-05-16  4:03   ` Claude review: " Claude Code Review Bot
2026-05-12  8:24 ` [PATCH v4 2/5] cgroup/dmem: Add reclaim callback for lowering max below current usage Thomas Hellström
2026-05-16  4:04   ` Claude review: " Claude Code Review Bot
2026-05-12  8:24 ` [PATCH v4 3/5] drm/ttm: Hook up a cgroup-aware reclaim callback for the dmem controller Thomas Hellström
2026-05-16  4:04   ` Claude Code Review Bot [this message]
2026-05-12  8:24 ` [PATCH v4 4/5] drm/xe: Wire up dmem cgroup reclaim for VRAM manager Thomas Hellström
2026-05-16  4:04   ` Claude review: " Claude Code Review Bot
2026-05-12  8:24 ` [PATCH v4 5/5] drm/amdgpu: " Thomas Hellström
2026-05-16  4:04   ` Claude review: " Claude Code Review Bot
2026-05-16  4:03 ` Claude review: Add reclaim to the dmem cgroup controller Claude Code Review Bot
  -- strict thread matches above, loose matches on Subject: below --
2026-05-11 17:30 [PATCH v3 0/5] " Thomas Hellström
2026-05-11 17:30 ` [PATCH v3 3/5] drm/ttm: Hook up a cgroup-aware reclaim callback for the dmem controller Thomas Hellström
2026-05-16  4:48   ` Claude review: " 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-patch3-20260512082406.44470-4-thomas.hellstrom@linux.intel.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