Re: Question on damon_sysfs_memcg_path_to_id() path resolution

On Wed, 12 Aug 2026 21:00:42 +0800 Song Hu <[email protected]> wrote:

> 
> Hi SJ,
> 
> Sorry for going quiet on this - things piled up and I let the thread sit.
> 
> 在 2026/7/21 12:43, SJ Park 写道:
> > 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!
> > 
> Glad it made sense. I owe you an actual answer to the question, though,
> not just the sketch.
> >>
> >> 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.
> > 
> Honestly I'm not sure either - that's exactly why I'd rather measure it
> than argue it. The bet, loosely: on a co-located node, when cpu.pressure
> climbs you shrink the best-effort footprint - fewer resident pages, fewer
> reclaims and faults fighting for the core, and memory given back to the
> latency-sensitive side. You're trading memory to buy back CPU. Whether it
> pays off, and how much, is what I don't know yet.
> 
> I've been building the thing I described so I can measure it. It's a
> per-cgroup, per-domain PSI daemon (C, libbpf) - it reads the pressure and,
> when adding resources doesn't make it converge, it tries to tell real
> scarcity from a leak or pathology before piling more on. A colleague and I
> are still debugging it.

Thank you for transparently sharing this.  And I agree, data will let us be
more enlightened, realistic and creative.

> 
> >>
> >> 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.
> > 
> That user_input goal is the handle I was missing - thanks. The plan is to
> wire DAMOS proactive reclaim to that goal as the memory actuator, feed it
> the cpu-pressure signal, and see what comes out. I'd rather get the data
> before the theory.

Sounds good.  Let me know if you find any problem at doing the experiments.  I
consider lab environment is also an important use case of DAMON.  I will be
happy to help.

> 
> >> 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.
> > 
> Agreed. I won't bring you a "goals should take a non-memory signal" request
> until I can show it actually helps - and if the numbers say so, I'll come
> with a real proposal.

Sounds good, I'm looking forward to the proposal!

> 
> >>
> >> Thanks for asking for the picture - stating it clarified it for me too.
> > 
> > I'm happy to help :)
> >
> Thanks for thinking it through with me.

You're welcome!

> 
> Thanks,
> Song
> 
> P.S. The code's at https://github.com/sharkct/tools_base_psi if you're ever
> curious - not a pitch, just something I've been having fun with :)

Thank you for sharing this!


Thanks,
SJ

[...]