Re: [PATCH 2/5] cgroup/dmem: Add reclaim callback for lowering max below current usage

Michal Koutný
2026-04-27T08:37:21Z

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Wed, Apr 22, 2026 at 12:36:50PM +0200, Thomas Hellström <thomas.hellstrom@linux.intel.com> wrote:
> > The task writing to max will not trigger a reclaim,
> > only set the new max value.
>
> I still read *synchronous* reclaim.
>
> >
> > But when a process, part of the affected cgroup, tries to allocate
> > memory,
> > it will be forced to reclaim memory until below max again.
> >
> > This is a workflow where instead of the updater doing all
> > the evictions, the evictions handled by a process in the cgroup
> > itself.
>
> But kswapd is still used to do background per-cgroup reclaim in this
> case, right?

kswapd is driven by the global zone watermarks, it would only reclaim in
the cgroup proportionally to its usage to fulfill that global "limit".
The actual memcg's memory.max doesn't affect kswapd, it's really when
reclaim is triggered upon hitting the limit from within the memcg.

(The background per-cgroup analogy of kswapd for memcgs is proactive
memory.reclaim but there's no dedicated kthread, it's up to the user to
decide when and what to write into memory.reclaim.)

HTH,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]