From: escape <escape@linux.alibaba.com>
To: Tejun Heo <tj@kernel.org>
Cc: hannes@cmpxchg.org, mkoutny@suse.com, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cgroup: replace global percpu_rwsem with signal_struct->group_rwsem when writing cgroup.procs/threads
Date: Thu, 4 Sep 2025 11:15:26 +0800 [thread overview]
Message-ID: <cfe595a7-c20d-4891-aba1-35546c488024@linux.alibaba.com> (raw)
In-Reply-To: <aLhykIPSGV1k_OG0@slm.duckdns.org>
在 2025/9/4 00:53, Tejun Heo 写道:
> Hello,
>
> On Wed, Sep 03, 2025 at 07:11:07PM +0800, Yi Tao wrote:
>> As computer hardware advances, modern systems are typically equipped
>> with many CPU cores and large amounts of memory, enabling the deployment
>> of numerous applications. On such systems, container creation and
>> deletion become frequent operations, making cgroup process migration no
>> longer a cold path. This leads to noticeable contention with common
>> process operations such as fork, exec, and exit.
> If you use CLONE_INTO_CGROUP, cgroup migration doesn't just become cold. It
> disappears completely and CLONE_INTO_CGROUP doesn't need any global locks
> from cgroup side. Are there reasons why you can't use CLONE_INTO_CGROUP?
>
> Thanks.
>
As Ridong pointed out, in the current code, using CLONE_INTO_CGROUP
still requires holding the threadgroup_rwsem, so contention with fork
operations persists.
CLONE_INTO_CGROUP helps alleviate the contention between cgroup creation
and deletion, but its usage comes with significant limitations:
1. CLONE_INTO_CGROUP is only available in cgroup v2. Although cgroup v2
adoption is gradually increasing, many applications have not yet been
adapted to cgroup v2, and phasing out cgroup v1 will be a long and
gradual process.
2. CLONE_INTO_CGROUP requires specifying the cgroup file descriptor at the
time of process fork, effectively restricting cgroup migration to the
fork stage. This differs significantly from the typical cgroup attach
workflow. For example, in Kubernetes, systemd is the recommended cgroup
driver; kubelet communicates with systemd via D-Bus, and systemd
performs the actual cgroup attachment. In this case, the process being
attached typically does not have systemd as its parent. Using
CLONE_INTO_CGROUP in such a scenario is impractical and would require
coordinated changes to both systemd and kubelet.
Thanks.
next prev parent reply other threads:[~2025-09-04 3:15 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 11:11 Yi Tao
2025-09-03 13:14 ` Waiman Long
2025-09-04 1:35 ` Chen Ridong
2025-09-04 4:59 ` escape
2025-09-04 5:02 ` escape
2025-09-03 16:53 ` Tejun Heo
2025-09-03 20:03 ` Michal Koutný
2025-09-03 20:45 ` Tejun Heo
2025-09-04 1:40 ` Chen Ridong
2025-09-04 6:43 ` escape
2025-09-04 6:52 ` Tejun Heo
2025-09-04 3:15 ` escape [this message]
2025-09-04 6:38 ` escape
2025-09-04 7:28 ` Tejun Heo
2025-09-04 8:10 ` escape
2025-09-04 11:39 ` [PATCH v2 0/1] " Yi Tao
2025-09-04 11:39 ` [PATCH v2 1/1] " Yi Tao
2025-09-04 16:31 ` Tejun Heo
2025-09-05 2:16 ` escape
2025-09-05 2:27 ` Tejun Heo
2025-09-05 3:44 ` escape
2025-09-05 3:48 ` Tejun Heo
2025-09-05 4:30 ` escape
2025-09-05 2:02 ` Chen Ridong
2025-09-05 13:17 ` kernel test robot
2025-09-08 10:20 ` [PATCH v3 0/1] cgroup: replace global percpu_rwsem with per threadgroup resem when writing to cgroup.procs Yi Tao
2025-09-08 10:20 ` [PATCH v3 1/1] " Yi Tao
2025-09-08 16:05 ` Tejun Heo
2025-09-08 19:39 ` Waiman Long
2025-09-09 7:55 ` [PATCH v4 0/3] " Yi Tao
2025-09-09 7:55 ` [PATCH v4 1/3] " Yi Tao
2025-09-09 7:55 ` [PATCH v4 2/3] cgroup: retry find task if threadgroup leader changed Yi Tao
2025-09-09 16:59 ` Tejun Heo
2025-09-09 7:55 ` [PATCH v4 3/3] cgroup: refactor the cgroup_attach_lock code to make it clearer Yi Tao
2025-09-09 17:00 ` Tejun Heo
2025-09-10 6:59 ` [PATCH v5 0/3] cgroup: replace global percpu_rwsem with per threadgroup resem when writing to cgroup.procs Yi Tao
2025-09-10 6:59 ` [PATCH v5 1/3] cgroup: refactor the cgroup_attach_lock code to make it clearer Yi Tao
2025-09-10 17:26 ` Tejun Heo
2025-09-10 6:59 ` [PATCH v5 2/3] cgroup: relocate cgroup_attach_lock within cgroup_procs_write_start Yi Tao
2025-09-10 17:31 ` Tejun Heo
2025-09-11 3:22 ` Waiman Long
2025-09-10 6:59 ` [PATCH v5 3/3] cgroup: replace global percpu_rwsem with per threadgroup resem when writing to cgroup.procs Yi Tao
2025-09-10 17:47 ` Tejun Heo
2025-09-11 1:52 ` Yi Tao
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=cfe595a7-c20d-4891-aba1-35546c488024@linux.alibaba.com \
--to=escape@linux.alibaba.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
/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
all inboxes | Powered by JetHome®