Re: [PATCH v7] cgroup/dmem: implement dmem.high soft limit with proactive reclaim

[Thomas Hellström]

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