From: Waiman Long <longman@redhat.com>
To: Christian Brauner <brauner@kernel.org>, Tejun Heo <tj@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>
Cc: Zefan Li <lizefan.x@bytedance.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
gscrivan@redhat.com
Subject: Re: CLONE_INTO_CGROUP probably needs to call controller attach handlers
Date: Tue, 28 Mar 2023 22:48:49 -0400 [thread overview]
Message-ID: <5937b51b-164a-b6b3-532d-43b46f2d49a2@redhat.com> (raw)
In-Reply-To: <c3d9cf24-1c3a-cda4-5063-6b7d27e9116f@redhat.com>
On 3/28/23 21:30, Waiman Long wrote:
> On 3/28/23 11:39, Christian Brauner wrote:
>> Hey,
>>
>> Giuseppe reported that the the affinity mask isn't updated when a
>> process is spawned directly into the target cgroup via
>> CLONE_INTO_CGROUP. However, migrating a process will cause the affinity
>> mask to be updated (see the repro at [1].
>>
>> I took a quick look and the issue seems to be that we don't call the
>> various attach handlers during CLONE_INTO_CGROUP whereas we do for
>> migration. So the solution seems to roughly be that we need to call the
>> various attach handlers during CLONE_INTO_CGROUP as well when the
>> parent's cgroups is different from the child cgroup. I think we need to
>> call all of them, can, cancel and attach.
>>
>> The plumbing here might be a bit intricate since the arguments that the
>> fork handlers take are different from the attach handlers.
>>
>> Christian
>>
>> [1]: https://paste.centos.org/view/f434fa1a
>>
> I saw that the current cgroup code already have the can_fork, fork and
> cancel_fork callbacks. Unfortunately such callbacks are not defined
> for cpuset yet. That is why the cpu affinity isn't correctly updated.
> I can post a patch to add those callback functions to cpuset which
> should then able to correctly address this issue.
Looking further into this issue, I am thinking that forking into a
cgroup should be equivalent to write the child pid into the
"cgroup.threads" file of the target cgroup. By taking this route, all
the existing can_attach, attach and cancel_attach methods can be used. I
believe the original fork method is for the limited use case of forking
into the same cgroup. So right now, only the pids controller has the
fork methods. Otherwise, we will have to modify a number of different
controllers to add the necessary fork methods. They will be somewhat
similar to the existing attach methods and so it will be a lot of
duplication. What do you think about this idea?
Cheers,
Longman
next prev parent reply other threads:[~2023-03-29 2:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 15:39 Christian Brauner
2023-03-28 15:41 ` Christian Brauner
2023-03-29 1:30 ` Waiman Long
2023-03-29 2:48 ` Waiman Long [this message]
2023-03-29 7:19 ` Christian Brauner
2023-03-31 18:27 ` Waiman Long
2023-03-29 14:52 ` Johannes Weiner
2023-03-29 17:43 ` Waiman Long
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=5937b51b-164a-b6b3-532d-43b46f2d49a2@redhat.com \
--to=longman@redhat.com \
--cc=brauner@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=gscrivan@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.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®