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

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

[Jing Wu]

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

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