From: <xu.xin16@zte.com.cn>
To: <akpm@linux-foundation.org>, <shakeel.butt@linux.dev>,
<hannes@cmpxchg.org>, <mhocko@kernel.org>,
<roman.gushchin@linux.dev>
Cc: <david@redhat.com>, <chengming.zhou@linux.dev>,
<xu.xin16@zte.com.cn>, <muchun.song@linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<cgroups@vger.kernel.org>
Subject: [PATCH v2 0/5] memcg: Support per-memcg KSM metrics
Date: Sun, 14 Sep 2025 18:00:31 +0800 (CST) [thread overview]
Message-ID: <20250914180031197jk6ngo5pQjpXkNtNsjzSo@zte.com.cn> (raw)
From: xu xin <xu.xin16@zte.com.cn>
Dear all,
This is the v2 of patchset, as Shakeel suggested:
https://lore.kernel.org/all/ir2s6sqi6hrbz7ghmfngbif6fbgmswhqdljlntesurfl2xvmmv@yp3w2lqyipb5/
With the enablement of container-level KSM (e.g., via prctl [1]), there is
a growing demand for container-level observability of KSM behavior. However,
current cgroup implementations lack support for exposing KSM-related metrics.
So add the counter in the existing memory.stat without adding a new interface.
To diaplay per-memcg KSM statistic counters, we traverse all processes of a
memcg and summing the processes' ksm_rmap_items counters instead of adding enum
item in memcg_stat_item or node_stat_item and updating the corresponding enum
counter when ksmd manipulate pages.
Now Linux users can look up all per-memcg KSM counters by:
# cat /sys/fs/cgroup/xuxin/memory.stat | grep ksm
ksm_rmap_items 0
ksm_zero_pages 0
ksm_merging_pages 0
ksm_profit 0
Q&A
====
why don't I add enum item in memcg_stat_item or node_stat_item like
other items in memory.stat ?
I tried the way of adding enum item in memcg_stat_item and updating them when
ksmd manipulate pages, but it failed with error statistic ksm counters of
memcg. This is because of the following reasons:
1) The KSM counter of memcgroup can be correctly incremented, but cannot be
properly decremented. E,g,, when ksmd scans pages of a process, it can use
the mm_struct of the struct ksm_rmap_item to reverse-lookup the memcg
and then increase the value via mod_memcg_state(memcg, MEMCG_KSM_COUNT, 1).
However, when the process exits abruptly, since ksmd asynchronously scans
the mmslot list in the background, it is no longer able to correctly locate
the original memcg through mm_struct by get_mem_cgroup_from_mm(), as the
task_struct has already been freed.
2) The first issue could potentially be addressed by adding a memcg
pointer directly into the ksm_rmap_item structure. However, this
increases memory overhead, especially when there are a large
number of ksm_rmap_items in the system (due to a high volume of
pages being scanned by ksmd). Moreover, this approach does not
resolve the same problem for ksm_zero_pages, because updates to
ksm_zero_pages are not performed through ksm_rmap_item, but
rather directly during unmap or page table entry (pte) faults
based on the mm_struct. At that point, if the process has
already exited, the corresponding memcg can no longer be
accurately identified.
xu xin (5):
memcg: add per-memcg ksm_rmap_items stat
memcg: show ksm_zero_pages count in memory.stat
memcg: show ksm_merging_pages in memory.stat
memcg: add per-memcg ksm_profit
Documentation: add KSM statistic counters description in cgroup-v2.rst
Documentation/admin-guide/cgroup-v2.rst | 17 +++++++
include/linux/ksm.h | 1 +
mm/ksm.c | 67 ++++++++++++++++++++++---
mm/memcontrol.c | 5 ++
4 files changed, 84 insertions(+), 6 deletions(-)
--
2.25.1
next reply other threads:[~2025-09-14 10:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-14 10:00 xu.xin16 [this message]
2025-09-14 10:03 ` [PATCH v2 1/5] memcg: add per-memcg ksm_rmap_items stat xu.xin16
2025-09-14 13:54 ` kernel test robot
2025-09-14 10:05 ` [PATCH v2 2/5] memcg: show ksm_zero_pages count in memory.stat xu.xin16
2025-09-14 10:06 ` [PATCH v2 3/5] memcg: show ksm_merging_pages " xu.xin16
2025-09-14 10:07 ` [PATCH v2 4/5] memcg: add per-memcg ksm_profit xu.xin16
2025-09-14 13:02 ` kernel test robot
2025-09-14 10:09 ` [PATCH v2 5/5] Documentation: add KSM statistic counters description in cgroup-v2.rst xu.xin16
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=20250914180031197jk6ngo5pQjpXkNtNsjzSo@zte.com.cn \
--to=xu.xin16@zte.com.cn \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
/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