Messages in this thread | | | Date | Mon, 3 Apr 2023 13:29:57 -0400 | Subject | Re: [PATCH 1/3] cgroup/cpuset: Make cpuset_fork() handle CLONE_INTO_CGROUP properly | From | Waiman Long <> |
| |
On 4/3/23 13:18, Waiman Long wrote: > > On 4/3/23 12:55, Michal Koutný wrote: >> On Fri, Mar 31, 2023 at 10:50:43AM -0400, Waiman Long >> <longman@redhat.com> wrote: >>> By default, the clone(2) syscall spawn a child process into the same >>> cgroup as its parent. With the use of the CLONE_INTO_CGROUP flag >>> introduced by commit ef2c41cf38a7 ("clone3: allow spawning processes >>> into cgroups"), the child will be spawned into a different cgroup which >>> is somewhat similar to writing the child's tid into "cgroup.threads". >>> >>> The current cpuset_fork() method does not properly handle the >>> CLONE_INTO_CGROUP case where the cpuset of the child may be different >>> from that of its parent. Update the cpuset_fork() method to treat the >>> CLONE_INTO_CGROUP case similar to cpuset_attach(). >> Should .can_fork=cpuset_can_fork in analogy to cpuset_can_attach be also >> devised? (Sorry if I missed that in the previous discussion.) > > I have thought about that too. > > However, the can_attach method checks only a couple of things: > > 1) PF_NO_SETAFFINITY flag - which won't be set in the case of fork() > as it is for kthread only. > 2) DL bandwidth - Juri has a cpuset outstanding to modify the way this > check is being done. I want to wait until it is settled before > tackling this, if necessary.
BTW, even cloning without CLONE_INTO_CGROUP can be an issue WRT DL bandwidth. So I will let the scheduler folk figure out what to do with that.
Cheers, Longman
| |