From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751198AbcGNLUw (ORCPT ); Thu, 14 Jul 2016 07:20:52 -0400 Received: from mail-qt0-f181.google.com ([209.85.216.181]:35991 "EHLO mail-qt0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbcGNLUt (ORCPT ); Thu, 14 Jul 2016 07:20:49 -0400 Date: Thu, 14 Jul 2016 07:20:46 -0400 From: Tejun Heo To: Peter Zijlstra Cc: "Paul E. McKenney" , John Stultz , Ingo Molnar , lkml , Dmitry Shmidt , Rom Lemarchand , Colin Cross , Todd Kjos , Oleg Nesterov Subject: Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes Message-ID: <20160714112046.GB15005@htj.duckdns.org> References: <20160713201823.GB29670@mtj.duckdns.org> <20160713202657.GW30154@twins.programming.kicks-ass.net> <20160713203944.GC29670@mtj.duckdns.org> <20160713205102.GZ30909@twins.programming.kicks-ass.net> <20160713210315.GO7094@linux.vnet.ibm.com> <20160713210526.GF29670@mtj.duckdns.org> <20160713211841.GQ7094@linux.vnet.ibm.com> <20160713220128.GA15005@htj.duckdns.org> <20160714064956.GC30909@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160714064956.GC30909@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 14, 2016 at 08:49:56AM +0200, Peter Zijlstra wrote: > On Wed, Jul 13, 2016 at 06:01:28PM -0400, Tejun Heo wrote: > > > Technically, I think the lglock approach would be better here given > > the combination of requirements; however, it's quite a bit more code > > which would likely require some sophistications down the line (like > > blocking new readers first at the start of down_write). > > So the immediate problem with lg style locks is that the 'local' lock > will not stay local since these are preemptible locks we can get > migrations etc.. > > All fixable, but still. In this case, the locks are read-locked only across operations which change process hierarchy. They'll occasionally get migrated while holding the lock for sure but not often enough to matter. > > If we have to > > go there, we'll go there but for now I think it'd be simpler to > > conditionally switch to the expedited operations. It can be a config > > option which is selected by !RT as you suggested. If anyone hits an > > actual issue with that, we can go for the lglock thing. > > So the main objection I have is that this isn't a fundamental fix, this > only cures things because Android only runs on small machines. > > If someone with a big computer tries to do the same things we're up some > creek without no paddle. There's just no way we can make a global writer > 'fast'. How so? As the number of cores increases, it'll get proportionally more expensive as the same operation is performed on more CPUs; however, the latency is dependent on the slowest one and it'll get higher more often with more number of CPUs but not drastically. Latency won't go up proportionally with the number of CPUs. For the most part, we're paying more in terms of processing overhead, not latency. Thanks. -- tejun