On Thu, 2026-07-09 at 14:11 +0800, Jing Wu wrote: > 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.
Sure. Let's notify eachother of imminent merge plans. I will rebase my series on yours if yours go in first. If needed let's look at a topic branch that we can merge into drm or vice versa. My work is stalled on lack of reviews ATM. Thanks, Thomas > > Thanks, > Jing Wu
