From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751216AbcGNMIw (ORCPT <rfc822;w@1wt.eu>);
	Thu, 14 Jul 2016 08:08:52 -0400
Received: from mail-qk0-f175.google.com ([209.85.220.175]:33713 "EHLO
	mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751115AbcGNMIt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 14 Jul 2016 08:08:49 -0400
Date: Thu, 14 Jul 2016 08:08:45 -0400
From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        John Stultz <john.stultz@linaro.org>, Ingo Molnar <mingo@redhat.com>,
        lkml <linux-kernel@vger.kernel.org>,
        Dmitry Shmidt <dimitrysh@google.com>,
        Rom Lemarchand <romlem@google.com>, Colin Cross <ccross@google.com>,
        Todd Kjos <tkjos@google.com>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: Severe performance regression w/ 4.4+ on Android due to cgroup
 locking changes
Message-ID: <20160714120845.GE15005@htj.duckdns.org>
References: <20160713210526.GF29670@mtj.duckdns.org>
 <20160713211841.GQ7094@linux.vnet.ibm.com>
 <20160713214238.GA15996@linux.vnet.ibm.com>
 <CALAqxLWoMVzUuSJM0uKXO25s4toXMceLFdKngzGNsAX7-+q0FA@mail.gmail.com>
 <20160713221750.GR7094@linux.vnet.ibm.com>
 <CALAqxLU880FGWM+sCha1LAi8KCtzreG2jrMEPU92PSHy2tOOJg@mail.gmail.com>
 <20160713230238.GU7094@linux.vnet.ibm.com>
 <20160713230404.GA2197@linux.vnet.ibm.com>
 <20160714113505.GC15005@htj.duckdns.org>
 <20160714120428.GZ30154@twins.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160714120428.GZ30154@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jul 14, 2016 at 02:04:28PM +0200, Peter Zijlstra wrote:
> > I think it probably makes sense to make this the default on !RT at
> > least with a separate patch w/o stable cc'd.  While most use cases
> > will be fine with the latency on write path, it also means that the
> > reader side is blocked for the duration which can hurt.  rwsem implies
> > a lot more readers and thus more read lock operations than writes.
> > It's weird to trade off higher latency for lower cpu usage when it
> > would also slow down all readers.
> 
> NAK, no expedited muck by default. There's more than just RT that
> doesn't like IPI sprays.

Can you elaborate?  If that's the case, we have the wrong implemention
for percpu-rwsem where very long delays for writers induce the same
level of delays to all readers.  If expedited by default isn't
workable, we should move away from rcu_sync for percpu_rwsem.

Thanks.

-- 
tejun