Re: Question on damon_sysfs_memcg_path_to_id() path resolution

On Mon, 20 Jul 2026 11:35:06 +0800 Song Hu <[email protected]> wrote:

[...]
> 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,

Sounds interesting!

> 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.

I'm sorry but I'm missing your points from here.  Could you elaborate why we
need the helper, and why DAMON should use it?

You're implementing your system in user-space, so I don't think you will use
that helper for your system.  DAMON has its internal implementation for reading
PSI.  What's the benefit of the helper compared to the current one?

Also that helper may be implemented inside PSI or cgroup subsystem and
maintained by the maintainers of the subsystems.  Are they willing to have this
and increase their maintenance burden?

> 
> 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.

Seems you have larger picture.  I don't clearly show what is it.  Could you
share it at a high level?  That might enlighten me.


Thanks,
SJ

[...]