On Wed, Jul 09, 2026 at 12:44:37AM -0700, Matthew Brost wrote:
> This looks quite similar to work Thomas is doing here [1].
Thank you for the pointer, Matt. We were not aware of Thomas's series
before your mail. After reviewing Thomas's v7 [1], the two series turn
out to address different — and complementary — problems:
- Thomas's series hooks a reclaim callback into the dmem.max write
path: when an administrator lowers dmem.max below current usage, the
kernel calls the driver's reclaim callback to bring device memory
usage down to the new limit. This is analogous to what happens in
memcg when memory.max is written below current usage.
- Our series adds dmem.high as a soft limit enforced in the charge
path: when a successful allocation pushes a cgroup's usage above
dmem.high, TTM proactively evicts one BO from that cgroup before
returning. This mirrors memory.high semantics in memcg, where
reclaim is triggered per-allocation to keep usage below the soft
threshold.
Both mechanisms coexist independently in memcg and serve distinct
purposes: the max write path handles capacity reconfiguration by
operators, while the high-limit path provides automatic backpressure
for workloads approaching their quota. Having both in the dmem cgroup
controller seems correct.
> Are either of you two aware of this seemly overlapping work?
We were not, until your mail. Now that we are, we would like to
coordinate with Thomas on a few interaction points:
1. API intersection: Thomas's v5+ replaces the bare u64 size argument
in dmem_cgroup_register_region() with struct dmem_cgroup_init (which
bundles the region size, reclaim ops, and driver private data). If
Thomas's series lands first, we will adapt our patches to the new
registration interface.
2. File-level conflicts: both series modify ttm_resource.c and
ttm_bo.c. The changes are semantically independent and should
compose cleanly after a rebase, whichever lands second.
Thomas, would you be open to coordinating on merge ordering? We are
happy to rebase our dmem.high series on top of yours once it lands, or
to split out any shared infrastructure as a common prerequisite if that
helps.
Thanks,
Jing Wu
