Re: Question on damon_sysfs_memcg_path_to_id() path resolution

在 2026/7/20 23:11, SJ Park 写道:
> 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?
On the helper: agreed - a userspace daemon reads PSI from the cgroup files
and DAMON already has its read, so there's no in-kernel consumer for it;
not the right place for kernel-side work. (And you're right that anything
on the PSI API is Johannes/Tejun's call, not DAMON's.)
>> 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.
>
The bigger picture, since you asked: I'm working on node-level multi-domain
(cpu + memory + io) resource coordination for container/K8S co-location -
online/latency-sensitive work sharing a node with offline/best-effort. PSI
per domain is the signal ("who is starved, on which domain"); cgroup
controllers are the actuators (cpu.weight/cpu.max, memory.low/reclaim,
io.weight/io.max). Adjust across domains to defend online SLOs while
keeping the node full. oomd, systemd-oomd and rubik each do one slice
today; nobody coordinates across domains, and that cross-domain part is
what I'm building.

What brought me to PSI/DAMON is the memory domain. DAMOS is already the
strongest memory actuator I'd want to orchestrate rather than reinvent -
proactive reclaim, per-memcg DAMOS goals, the PSI-aware quota - except
DAMOS goals today only take memory-domain signals (mem PSI, mem usage). For
a cross-domain coordinator the useful step is making memory-domain reclaim
also respond to non-memory pressure (e.g. shrink offline footprint when
cpu.pressure rises).

So the honest question, which I think is where this actually meets the
kernel: is the pattern you'd prefer that an orchestrator just adjust DAMOS
schemes over sysfs in response to external pressure, or have you thought
about DAMOS goals accepting non-memory signals (cpu/io PSI, or generic)?
I'm asking which side of that line you'd want it on, not pushing either.

Thanks for asking for the picture - stating it clarified it for me too.

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