From: Christian Brauner <christian.brauner@ubuntu.com> To: Peter Zijlstra <peterz@infradead.org> Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, Li Zefan <lizefan@huawei.com>, cgroups@vger.kernel.org Subject: Re: [PATCH v5 5/6] clone3: allow spawning processes into cgroups Date: Tue, 4 Feb 2020 16:01:44 +0100 [thread overview] Message-ID: <20200204150144.fojbdmuyr7bnvgnj@wittgenstein> (raw) In-Reply-To: <20200204115351.GD14879@hirez.programming.kicks-ass.net> On Tue, Feb 04, 2020 at 12:53:51PM +0100, Peter Zijlstra wrote: > On Tue, Jan 21, 2020 at 04:48:43PM +0100, Christian Brauner wrote: > > This adds support for creating a process in a different cgroup than its > > parent. Callers can limit and account processes and threads right from > > the moment they are spawned: > > - A service manager can directly spawn new services into dedicated > > cgroups. > > - A process can be directly created in a frozen cgroup and will be > > frozen as well. > > - The initial accounting jitter experienced by process supervisors and > > daemons is eliminated with this. > > - Threaded applications or even thread implementations can choose to > > create a specific cgroup layout where each thread is spawned > > directly into a dedicated cgroup. > > > > This feature is limited to the unified hierarchy. Callers need to pass > > an directory file descriptor for the target cgroup. The caller can > > choose to pass an O_PATH file descriptor. All usual migration > > restrictions apply, i.e. there can be no processes in inner nodes. In > > general, creating a process directly in a target cgroup adheres to all > > migration restrictions. > > AFAICT, he *big* win here is avoiding the write side of the > cgroup_threadgroup_rwsem. Or am I mis-reading the patch? No, you're absolutely right. I just didn't bother putting implementation specifics in the cover letter and I probably should have. So thanks for pointing that out! > > That global lock is what makes moving tasks/threads around super > expensive, avoiding that by use of this clone() variant wins the day. :) Christian
WARNING: multiple messages have this Message-ID (diff)
From: Christian Brauner <christian.brauner-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> To: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v5 5/6] clone3: allow spawning processes into cgroups Date: Tue, 4 Feb 2020 16:01:44 +0100 [thread overview] Message-ID: <20200204150144.fojbdmuyr7bnvgnj@wittgenstein> (raw) In-Reply-To: <20200204115351.GD14879-Nxj+rRp3nVydTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> On Tue, Feb 04, 2020 at 12:53:51PM +0100, Peter Zijlstra wrote: > On Tue, Jan 21, 2020 at 04:48:43PM +0100, Christian Brauner wrote: > > This adds support for creating a process in a different cgroup than its > > parent. Callers can limit and account processes and threads right from > > the moment they are spawned: > > - A service manager can directly spawn new services into dedicated > > cgroups. > > - A process can be directly created in a frozen cgroup and will be > > frozen as well. > > - The initial accounting jitter experienced by process supervisors and > > daemons is eliminated with this. > > - Threaded applications or even thread implementations can choose to > > create a specific cgroup layout where each thread is spawned > > directly into a dedicated cgroup. > > > > This feature is limited to the unified hierarchy. Callers need to pass > > an directory file descriptor for the target cgroup. The caller can > > choose to pass an O_PATH file descriptor. All usual migration > > restrictions apply, i.e. there can be no processes in inner nodes. In > > general, creating a process directly in a target cgroup adheres to all > > migration restrictions. > > AFAICT, he *big* win here is avoiding the write side of the > cgroup_threadgroup_rwsem. Or am I mis-reading the patch? No, you're absolutely right. I just didn't bother putting implementation specifics in the cover letter and I probably should have. So thanks for pointing that out! > > That global lock is what makes moving tasks/threads around super > expensive, avoiding that by use of this clone() variant wins the day. :) Christian
next prev parent reply other threads:[~2020-02-04 15:01 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-21 15:48 [PATCH v5 0/6] clone3 & cgroups: allow spawning processes into cgroups Christian Brauner 2020-01-21 15:48 ` Christian Brauner 2020-01-21 15:48 ` [PATCH v5 1/6] cgroup: unify attach permission checking Christian Brauner 2020-01-29 13:25 ` Michal Koutný 2020-01-21 15:48 ` [PATCH v5 2/6] cgroup: add cgroup_get_from_file() helper Christian Brauner 2020-01-29 13:25 ` Michal Koutný 2020-01-29 13:25 ` Michal Koutný 2020-01-21 15:48 ` [PATCH v5 3/6] cgroup: refactor fork helpers Christian Brauner 2020-01-29 13:26 ` Michal Koutný 2020-01-29 13:26 ` Michal Koutný 2020-01-21 15:48 ` [PATCH v5 4/6] cgroup: add cgroup_may_write() helper Christian Brauner 2020-01-21 15:48 ` [PATCH v5 5/6] clone3: allow spawning processes into cgroups Christian Brauner 2020-01-21 15:48 ` Christian Brauner 2020-01-21 15:48 ` Christian Brauner 2020-01-29 13:27 ` Michal Koutný 2020-01-29 13:27 ` Michal Koutný 2020-02-02 9:37 ` Christian Brauner 2020-02-02 9:37 ` Christian Brauner 2020-02-02 9:37 ` Christian Brauner 2020-02-03 14:32 ` Michal Koutný 2020-02-03 14:32 ` Michal Koutný 2020-02-04 11:13 ` Christian Brauner 2020-02-04 11:13 ` Christian Brauner 2020-02-04 11:13 ` Christian Brauner 2020-02-04 11:53 ` Peter Zijlstra 2020-02-04 15:01 ` Christian Brauner [this message] 2020-02-04 15:01 ` Christian Brauner 2020-01-21 15:48 ` [PATCH v5 6/6] selftests/cgroup: add tests for cloning " Christian Brauner
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=20200204150144.fojbdmuyr7bnvgnj@wittgenstein \ --to=christian.brauner@ubuntu.com \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan@huawei.com \ --cc=mingo@redhat.com \ --cc=oleg@redhat.com \ --cc=peterz@infradead.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.