Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752230AbbEXCgg (ORCPT ); Sat, 23 May 2015 22:36:36 -0400 Received: from [119.145.14.66] ([119.145.14.66]:49179 "EHLO szxga03-in.huawei.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751456AbbEXCgb (ORCPT ); Sat, 23 May 2015 22:36:31 -0400 Message-ID: <55613904.7060502@huawei.com> Date: Sun, 24 May 2015 10:35:48 +0800 From: Zefan Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tejun Heo CC: Peter Zijlstra , , , Subject: Re: [PATCH 2/3] sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem References: <1431549318-16756-1-git-send-email-tj@kernel.org> <1431549318-16756-3-git-send-email-tj@kernel.org> <20150519151659.GF3644@twins.programming.kicks-ass.net> <20150519155133.GM24861@htj.duckdns.org> <555C5C71.80200@huawei.com> <20150521203943.GS24861@htj.duckdns.org> In-Reply-To: <20150521203943.GS24861@htj.duckdns.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.18.230] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5561390C.00CB,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6983a3061de5b61aed9b3699acf783a2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1468 Lines: 35 On 2015/5/22 4:39, Tejun Heo wrote: > Hello, Li. > > On Wed, May 20, 2015 at 06:05:37PM +0800, Zefan Li wrote: >>> 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. > > It's still not a very frequent operation tho. We're talking about > users switching fore/background jobs here and the expedited > synchronization w/ preemption enabled doesn't take much time. In > addition, as it currently stands, android is doing memory charge > immigration on each fore/background switches. I'm pretty doubtful > this would make any difference. > I did some testing with my laptop. Moving a task between 2 cgroups for 10W times with one or two threads: 1T 2T orig 3.36s 3.65s orig+tj 3.55s 6.31s orig+sync_rcu 16.69s 28.47s (only 1000 times) The overhead looks acceptable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/