From: SJ Park <sj@kernel.org>
To: Song Hu <husong@kylinos.cn>
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: Question on damon_sysfs_memcg_path_to_id() path resolution
Date: Sat, 18 Jul 2026 08:59:51 -0700 [thread overview]
Message-ID: <20260718155952.26350-1-sj@kernel.org> (raw)
In-Reply-To: <04cc010d-5b8c-486d-b4d4-59cbe6dcab8b@kylinos.cn>
On Sat, 18 Jul 2026 16:40:51 +0800 Song Hu <husong@kylinos.cn> wrote:
> Hi,
>
> Sorry for the late reply.
No worry!
[...]
> > I find the current behavior might be tedious if the user runs DAMON inside
> > cgroups. Finding the absolute cgroup path inside containers might be
> > challenging. If that's the case, I'm up to change or extend the behaviors.
> >
> > If this is only for making the code easier to maintain, I don't really feel
> > like it deserves the behavioral changes, to be honest.
> I looked into the container case more carefully and I'm no longer sure
> it justifies the change.
>
> DAMON sysfs is root-only (state is 0600 under /sys/kernel/mm/damon), so
> whoever configures a scheme is effectively a host-level operator. That
> operator can obtain the absolute cgroup path directly (e.g. from
> /proc/<pid>/cgroup), and the usage docs already show host-absolute
> paths. A process able to write host DAMON sysfs from inside a non-init
> cgroup namespace is a privileged host-admin case, not really a "DAMON
> inside a container" user. So I think the namespace-relative benefit is
> marginal at best.
>
> Given that, and your point that maintainability alone isn't worth a
> behavioral change, I'll leave damon_sysfs_memcg_path_to_id() as-is.
Makes sense.
>
> Thanks for thinking it through with me -- and for the cgroup_get_from_path pointer.
You're welcome. I liked this dicsussion. Looking forward to the next one!
Thanks,
SJ
[...]
prev parent reply other threads:[~2026-07-18 16:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 6:35 Question on damon_sysfs_memcg_path_to_id() path resolution Song Hu
2026-07-15 13:51 ` SJ Park
2026-07-18 8:40 ` Song Hu
2026-07-18 15:59 ` SJ Park [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260718155952.26350-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=husong@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox