Re: [PATCH v2 0/3] cgroup/dmem: allow atomic irrestrictive writes to dmem.max

[Thadeu Lima de Souza Cascardo]

On Wed, Mar 25, 2026 at 06:40:40PM +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Den 2026-03-23 kl. 18:37, skrev Thadeu Lima de Souza Cascardo:
> > On Mon, Mar 23, 2026 at 05:46:28PM +0100, Maarten Lankhorst wrote:
> >> Hey,
> >>
> >>
> >> Den 2026-03-21 kl. 20:27, skrev Tejun Heo:
> >>> Hello,
> >>>
> >>> Generally looks okay to me. One comment on 3/3 — the naked xchg() in
> >>> set_resource_max() needs a comment explaining why it's used instead of
> >>> page_counter_set_max() and what the semantics are (unconditionally sets max
> >>> regardless of current usage to prevent further allocations, since there's no
> >>> eviction mechanism yet).
> >>>
> >>> Applied 1/3. Maarten, Michal, what do you think?
> >>
> >> Yeah probably drop 2/3 too since there is no longer a case where setting a limit may fail.
> >>
> >> Kind regards,
> >> ~Maarten Lankhorst
> > 
> > Actually, this can still happen if an invalid region name is given.
> > 
> > So, one could write:
> > 
> > echo -e 'region1 max\ninvalidregion2 max\n' > dmem.max
> > 
> > And even though setting the value for region1 would be applied, the write
> > would return -EINVAL.
> 
> Makes sense. It would be good to validate in advance then. If that's not possible we
> should at least not error when we try to update 2 regions simultaneously. Likely the
> best to do so anyway if we want to handle eviction, which may be handled in a blocking
> fashion.
> 
> Kind regards,
> ~Maarten Lankhorst

I have submitted only the last patch with the additional comment for now.

If it turns out that eviction is handled, you bring up a good point that
doing it in a blocking fashion may lead to an underisable effect where
setting the max and starting eviction for one region may be delayed by the
eviction of a previous region.

Is there any reason to keep the support for handling multiple regions in a
single write?

Thanks.
Cascardo.