Re: Question on damon_sysfs_memcg_path_to_id() path resolution

On Tue, 21 Jul 2026 10:03:07 +0800 Song Hu <[email protected]> wrote:
[...]
> >> 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.

Thank you for sharing the big picture.  Sounds very interesting!

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

That's a very interesting idea.  I'm not quite sure what would be the expected
result of doing cpu pressure based proactive memory reclamation, though.

> 
> 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 haven't thought such things.  That's only because I was unable to imagine a
use case that will benefit from that.  If you have some theories and/or data,
please feel free to propose changes.

FYI, DAMOS supports arbitrary 'user_input' for a quota goal.  You will be able
to do some experiments using it.

> I'm asking which side of that line you'd want it on, not pushing either.

No worry.  I prefer DAMON to keep doing random evolution for providing benefits
to the users.  If you have use cases that can benefit from some changes in
DAMON, please don't hesitate at asking questions and proposing changes.

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

I'm happy to help :)

[1] https://origin.kernel.org/doc/html/latest/mm/damon/design.html#aim-oriented-feedback-driven-auto-tuning


Thanks,
SJ

[...]