From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753613AbbGOTA7 (ORCPT ); Wed, 15 Jul 2015 15:00:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44107 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753385AbbGOTA5 (ORCPT ); Wed, 15 Jul 2015 15:00:57 -0400 Date: Wed, 15 Jul 2015 20:59:14 +0200 From: Oleg Nesterov To: "Paul E. McKenney" Cc: Linus Torvalds , Peter Zijlstra , Daniel Wagner , Davidlohr Bueso , Ingo Molnar , Tejun Heo , linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/7] percpu-rwsem: change it to rely on rss_sync infrastructure Message-ID: <20150715185914.GB2101@redhat.com> References: <20150711233535.GA829@redhat.com> <20150711233601.GA863@redhat.com> <20150715181507.GK3717@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150715181507.GK3717@linux.vnet.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/15, Paul E. McKenney wrote: > > On Sun, Jul 12, 2015 at 01:36:01AM +0200, Oleg Nesterov wrote: > > Currently down_write/up_write calls synchronize_sched_expedited() > > twice which is evil. Change this code to rely on rcu-sync primitives. > > This avoids the _expedited "big hammer", and this can be faster in > > the contended case or even in the case when a single thread does > > down_write/up_write in a loop. > > But "evil" is such a strong word! ;-) I tried to be convincive ;) But yes, to me this synchronize_sched_expedited() looks really annoying because it is not friendly to other workloads. > More seriously, introducing a read-side smp_mb() Sure, we can penalize the readers and simplify this code. But the main purpose of this primitive was "make the readers fast". I'll write another email about this... > My main concern would be the introduction of an exclusive lock for the > writer, but if you are hitting the write-side acquisition that hard, > perhaps you are having other bigger problems. Sorry, I don't really understand... could you explain? > Another concern would be performance in a workload where there are way > more readers than writers, but enough writers so that there is not much > more than one grace period's worth of spacing between them. In that case, > the readers are having to hit the global lock more frequently with this > change than in the original. Of course, this is true. Oleg.