Re: Question on damon_sysfs_memcg_path_to_id() path resolution

在 2026/7/18 23:59, SJ Park 写道:
> On Sat, 18 Jul 2026 16:40:51 +0800 Song Hu <[email protected]> wrote:
>
>> Hi,
>>
>> Sorry for the late reply.
> No worry!
>
> [...]
>>> I find the current behavior might be tedious if the user runs DAMON inside
>>> cgroups.  Finding the absolute cgroup path inside containers might be
>>> challenging.  If that's the case, I'm up to change or extend the behaviors.
>>>
>>> If this is only for making the code easier to maintain, I don't really feel
>>> like it deserves the behavioral changes, to be honest.
>> I looked into the container case more carefully and I'm no longer sure
>> it justifies the change.
>>
>> DAMON sysfs is root-only (state is 0600 under /sys/kernel/mm/damon), so
>> whoever configures a scheme is effectively a host-level operator.  That
>> operator can obtain the absolute cgroup path directly (e.g. from
>> /proc/<pid>/cgroup), and the usage docs already show host-absolute
>> paths.  A process able to write host DAMON sysfs from inside a non-init
>> cgroup namespace is a privileged host-admin case, not really a "DAMON
>> inside a container" user.  So I think the namespace-relative benefit is
>> marginal at best.
>>
>> Given that, and your point that maintainability alone isn't worth a
>> behavioral change, I'll leave damon_sysfs_memcg_path_to_id() as-is.
> Makes sense.
>
>> Thanks for thinking it through with me -- and for the cgroup_get_from_path pointer.
> You're welcome.  I liked this dicsussion.  Looking forward to the next one!
Following up on our last chat - thanks again for the cgroup_get_from_path
pointer, that settled it for me. One thing it got me thinking about, which
I'd like to get your read on before I write any code.

The only in-kernel PSI consumer today is DAMON, and it reads a single
system-wide value - psi_system.total for memory (mm/damon/core.c,
damos_get_some_mem_psi_total). There is no reusable in-kernel helper that
returns per-cgroup, multi-domain (cpu/mem/io x some/full) pressure as a
value (psi_show is a seq_file printer for the /proc and cgroup files, not a
value-returning API), and no in-kernel threshold-trigger (psi_trigger_create
is userspace-fd only).

I'm writing a node-level multi-domain (cpu + memory + io) resource
coordinator for container/Kubernetes nodes - a small C daemon using libbpf
plus PSI trigger fds. To attribute pressure to specific cgroups and act
across domains it needs per-cgroup, per-domain PSI, which today means
open-coding reads of cgroup_psi(cgrp)->total[] the way DAMON does in-kernel.
And I think DAMON's own per-memcg DAMOS quota goals would benefit from the
same per-cgroup read if it existed.

So the idea is a small helper, e.g.

  /* per-cgroup, per-domain pressure; reuses update_averages() */
  u64 psi_cgroup_total(struct cgroup *cgrp, enum psi_res res, bool some);
  /* and/or an avg10/60/300 variant */

with DAMON migrated to it as the first in-tree user.

Before I do anything: does this capability gap resonate with you - is
per-cgroup PSI consumption something you'd want DAMON to grow into, or do
you see it staying userspace-only? And if a helper makes sense, any
preferred shape, or concerns about exposing the averaging/locking contract?
I'd keep the first cut to just the read helper + DAMON migration; an
in-kernel trigger callback I'd treat as a separate, later step and only if
there's a second consumer.

Thanks,
Song
>
> Thanks,
> SJ
>
> [...]