From: Johannes Weiner <hannes@cmpxchg.org>
To: jingxiang zeng <jingxiangzeng.cas@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev,
kasong@tencent.com, Zeng Jingxiang <linuszeng@tencent.com>
Subject: Re: [RFC 0/5] add option to restore swap account to cgroupv1 mode
Date: Thu, 20 Mar 2025 11:08:23 -0400 [thread overview]
Message-ID: <20250320144722.GH1876369@cmpxchg.org> (raw)
In-Reply-To: <CAJqJ8ig7BrPp0H3Lzbd0u9R6RhS5V0-i3b4eMWf+4EhujRU-jw@mail.gmail.com>
On Thu, Mar 20, 2025 at 04:09:29PM +0800, jingxiang zeng wrote:
> If both memsw.max and swap.max are provided in cgroupv2, there will be some
> issues as follows:
> (1. As Shakeel Butt mentioned, currently memsw and swap share the page_counter,
> and we need to provide a separate page_counter for memsw.
> (2. Currently, the statistics for memsw and swap are mutually
> exclusive. For example,
> during uncharging, both memsw and swap call the __mem_cgroup_uncharge_swap
> function together, and this function currently only selects a single
> counter for statistics
> based on the static do_memsw_account.
My suggestion is to factor out from struct page_counter all the stuff
that is not necessary for all users, and then have separate counters
for swap and memsw.
The protection stuff is long overdue for this. It makes up nearly half
of the struct's members, but is only used by the memory counter. Even
before your patches this is unnecessary bloat in the swap/memsw, kmem
and tcpmem counters.
Fix that and having separate counters is a non-issue.
Overloading the memory.swap.* controls to mean "combined memory and
swap" is unacceptable to me. They have established meaning on v2. It
may well become a common setting, and there might well be usecases
where people want one setting for one cgroup and another setting for
another cgroup. Or maybe even both controls in one group. And why not?
This is a user-visible interface that we'll have to support forever,
and deployments will be forced to use forever. Tech debt in the
current implementation is not a convincing argument to forever trap us
all with a suboptimal choice.
Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
prev parent reply other threads:[~2025-03-20 15:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 6:41 [RFC 0/5] add option to restore swap account to cgroupv1 mode Jingxiang Zeng
2025-03-19 6:41 ` [RFC 1/5] Kconfig: add SWAP_CHARGE_V1_MODE config Jingxiang Zeng
2025-03-19 19:29 ` Shakeel Butt
2025-03-19 19:31 ` Shakeel Butt
2025-03-19 6:41 ` [RFC 2/5] memcontrol: add boot option to enable memsw account on dfl Jingxiang Zeng
2025-03-19 19:34 ` Shakeel Butt
2025-03-19 22:30 ` Roman Gushchin
2025-03-20 8:43 ` jingxiang zeng
2025-03-20 14:28 ` Johannes Weiner
2025-03-20 15:16 ` Roman Gushchin
2025-03-20 15:33 ` Shakeel Butt
2025-04-02 13:40 ` Michal Koutný
2025-04-03 7:47 ` [External] " Zhongkun He
2025-04-03 9:16 ` jingxiang zeng
2025-04-11 16:57 ` Michal Koutný
2025-04-16 8:29 ` jingxiang zeng
2025-05-05 18:29 ` Michal Koutný
2025-03-20 8:51 ` jingxiang zeng
2025-03-19 6:41 ` [RFC 3/5] mm/memcontrol: do not scan anon pages if memsw limit is hit Jingxiang Zeng
2025-03-19 19:36 ` Shakeel Butt
2025-03-20 8:40 ` jingxiang zeng
2025-03-19 6:41 ` [RFC 4/5] mm/memcontrol: allow memsw account in cgroup v2 Jingxiang Zeng
2025-03-19 6:41 ` [RFC 5/5] Docs/cgroup-v2: add cgroup.memsw_account_on_dfl Documentation Jingxiang Zeng
2025-03-19 19:27 ` [RFC 0/5] add option to restore swap account to cgroupv1 mode Shakeel Butt
2025-03-19 19:38 ` Johannes Weiner
2025-03-19 19:51 ` Shakeel Butt
2025-03-20 8:09 ` jingxiang zeng
2025-03-20 15:08 ` Johannes Weiner [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=20250320144722.GH1876369@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=jingxiangzeng.cas@gmail.com \
--cc=kasong@tencent.com \
--cc=linuszeng@tencent.com \
--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