From: Zefan Li <lizefan@huawei.com> To: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org>, <cgroups@vger.kernel.org>, <mingo@redhat.com>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 2/3] sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem Date: Wed, 20 May 2015 18:05:37 +0800 [thread overview] Message-ID: <555C5C71.80200@huawei.com> (raw) In-Reply-To: <20150519155133.GM24861@htj.duckdns.org> On 2015/5/19 23:51, Tejun Heo wrote: > Hello, Peter. > > On Tue, May 19, 2015 at 05:16:59PM +0200, Peter Zijlstra wrote: >> .gitconfig: >> >> [diff "default"] >> xfuncname = "^[[:alpha:]$_].*[^:]$" >> >> Will avoid keying on labels like that and show us this is >> __cgroup_procs_write(). > > Ah, nice trick. > >> So my only worry with this patch-set is that these operations will be >> hugely expensive. >> >> Now it looks like the cgroup_update_dfl_csses() thing is very rare, its >> when you change which controllers are active in a given subtree under >> the uber-l337-super-comount design. >> >> The other one, __cgorup_procs_write() is every /procs, /tasks write to a >> cgroup, and that does worry me, this could be a somewhat common thing. >> >> The Changelog states task migration is a cold path, but is tens of >> miliseconds per task really no problem? > > The latency is bound by synchronize_sched_expedited(). Given the way > cgroups are used in majority of setups (process migration happening > only during service / session setups), I think this should be okay. > Actually process migration can happen quite frequently, for example in Android phones, and that's why Google had an out-of-tree patch to remove the synchronize_rcu() in that path, which turned out to be buggy. > I agree that something which is closer to lglock in characteristics > would fit the workload better tho. If this actually becomes a > problem, we can come up with a different percpu locking scheme which > puts a bit more overhead on the reader side to reduce the latency / > overhead on the writer side which shouldn't be that difficult but > let's see whether we need to get there at all. > > Thanks. >
WARNING: multiple messages have this Message-ID (diff)
From: Zefan Li <lizefan@huawei.com> To: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org>, cgroups@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem Date: Wed, 20 May 2015 18:05:37 +0800 [thread overview] Message-ID: <555C5C71.80200@huawei.com> (raw) In-Reply-To: <20150519155133.GM24861@htj.duckdns.org> On 2015/5/19 23:51, Tejun Heo wrote: > Hello, Peter. > > On Tue, May 19, 2015 at 05:16:59PM +0200, Peter Zijlstra wrote: >> .gitconfig: >> >> [diff "default"] >> xfuncname = "^[[:alpha:]$_].*[^:]$" >> >> Will avoid keying on labels like that and show us this is >> __cgroup_procs_write(). > > Ah, nice trick. > >> So my only worry with this patch-set is that these operations will be >> hugely expensive. >> >> Now it looks like the cgroup_update_dfl_csses() thing is very rare, its >> when you change which controllers are active in a given subtree under >> the uber-l337-super-comount design. >> >> The other one, __cgorup_procs_write() is every /procs, /tasks write to a >> cgroup, and that does worry me, this could be a somewhat common thing. >> >> The Changelog states task migration is a cold path, but is tens of >> miliseconds per task really no problem? > > The latency is bound by synchronize_sched_expedited(). Given the way > cgroups are used in majority of setups (process migration happening > only during service / session setups), I think this should be okay. > Actually process migration can happen quite frequently, for example in Android phones, and that's why Google had an out-of-tree patch to remove the synchronize_rcu() in that path, which turned out to be buggy. > I agree that something which is closer to lglock in characteristics > would fit the workload better tho. If this actually becomes a > problem, we can come up with a different percpu locking scheme which > puts a bit more overhead on the reader side to reduce the latency / > overhead on the writer side which shouldn't be that difficult but > let's see whether we need to get there at all. > > Thanks. >
next prev parent reply other threads:[~2015-05-20 10:06 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-13 20:35 [PATCHSET] cgroup, sched: restructure threadgroup locking and replace it with a percpu_rwsem Tejun Heo 2015-05-13 20:35 ` Tejun Heo 2015-05-13 20:35 ` [PATCH 1/3] sched, cgroup: reorganize threadgroup locking Tejun Heo 2015-05-13 20:35 ` Tejun Heo 2015-05-14 1:09 ` Sergey Senozhatsky 2015-05-14 1:09 ` Sergey Senozhatsky 2015-05-14 15:17 ` Tejun Heo 2015-05-14 15:17 ` Tejun Heo 2015-05-13 20:35 ` [PATCH 2/3] sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem Tejun Heo 2015-05-19 15:16 ` Peter Zijlstra 2015-05-19 15:51 ` Tejun Heo 2015-05-19 15:51 ` Tejun Heo 2015-05-20 10:05 ` Zefan Li [this message] 2015-05-20 10:05 ` Zefan Li 2015-05-21 20:39 ` Tejun Heo 2015-05-21 20:39 ` Tejun Heo 2015-05-24 2:35 ` Zefan Li 2015-05-24 2:35 ` Zefan Li 2015-05-13 20:35 ` [PATCH 3/3] cgroup: simplify threadgroup locking Tejun Heo 2015-05-18 16:34 ` [PATCHSET] cgroup, sched: restructure threadgroup locking and replace it with a percpu_rwsem Tejun Heo 2015-05-18 16:34 ` Tejun Heo 2015-05-18 20:06 ` Peter Zijlstra 2015-05-18 20:06 ` Peter Zijlstra 2015-05-27 0:34 ` Tejun Heo 2015-05-27 0:34 ` Tejun Heo
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=555C5C71.80200@huawei.com \ --to=lizefan@huawei.com \ --cc=cgroups@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@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.