Re: Question on damon_sysfs_memcg_path_to_id() path resolution

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.

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

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

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

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 :)
 
> [1] https://origin.kernel.org/doc/html/latest/mm/damon/design.html#aim-oriented-feedback-driven-auto-tuning
> 
> 
> Thanks,
> SJ
> 
> [...]