Re: [PATCH 0/8] memcg: separate private and public ID namespaces

[SeongJae Park <sj@kernel.org>]

On Thu, 25 Dec 2025 15:21:08 -0800 Shakeel Butt <shakeel.butt@linux.dev> wrote:

> The memory cgroup subsystem maintains a private ID infrastructure that
> is decoupled from the cgroup IDs. This private ID system exists because
> some kernel objects (like swap entries and shadow entries in the
> workingset code) can outlive the cgroup they were associated with.
> The motivation is best described in commit 73f576c04b941 ("mm:
> memcontrol: fix cgroup creation failure after many small jobs").
> 
> Unfortunately, some in-kernel users (DAMON, LRU gen debugfs interface,
> shrinker debugfs) started exposing these private IDs to userspace.

Technically speaking, DAMON is not exposing the private IDs to userspace.  It
does use the ids to specify the memory cgroups in kernel space.  But, when it
communicates with the user space, it uses the paths of the cgroups, not the
ids.

> This is problematic because:
> 
> 1. The private IDs are internal implementation details that could change
> 2. Userspace already has access to cgroup IDs through the cgroup
>    filesystem
> 3. Using different ID namespaces in different interfaces is confusing

Though DAMON is not exposing the IDs to the userspace, I agree it is better to
use public id, mainly because DAMON doesn't really care about the
cgroup-outlive objects.  Also, it would allow easier change of the
implementation details and make more consistent kernel-space API usages.


Thanks,
SJ

[...]