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 S935026AbdDSPhO (ORCPT <rfc822;w@1wt.eu>);
        Wed, 19 Apr 2017 11:37:14 -0400
Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41599 "EHLO
        mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1765966AbdDSPhM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 19 Apr 2017 11:37:12 -0400
Date: Wed, 19 Apr 2017 08:37:03 -0700
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com,
        dipankar@in.ibm.com, akpm@linux-foundation.org,
        mathieu.desnoyers@efficios.com, josh@joshtriplett.org,
        tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com,
        edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com,
        oleg@redhat.com, bobby.prani@gmail.com, marc.zyngier@arm.com
Subject: Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
Reply-To: paulmck@linux.vnet.ibm.com
References: <20170412165441.GA17149@linux.vnet.ibm.com>
 <20170417232714.GA19013@linux.vnet.ibm.com>
 <20170419112845.3rt3zlyzuzert647@hirez.programming.kicks-ass.net>
 <20170419130245.GJ3956@linux.vnet.ibm.com>
 <20170419131553.cii62nl2si3lwm7w@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170419131553.cii62nl2si3lwm7w@hirez.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-TM-AS-GCONF: 00
x-cbid: 17041915-0048-0000-0000-000001619A07
X-IBM-SpamModules-Scores: 
X-IBM-SpamModules-Versions: BY=3.00006939; HX=3.00000240; KW=3.00000007;
 PH=3.00000004; SC=3.00000208; SDB=6.00849655; UDB=6.00419567; IPR=6.00628289;
 BA=6.00005304; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000;
 ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015095; XFM=3.00000013;
 UTC=2017-04-19 15:37:08
X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused
x-cbparentid: 17041915-0049-0000-0000-0000409F41D0
Message-Id: <20170419153703.GQ3956@linux.vnet.ibm.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-19_13:,,
 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2
 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
 adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000
 definitions=main-1704190130
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 19, 2017 at 03:15:53PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 19, 2017 at 06:02:45AM -0700, Paul E. McKenney wrote:
> > On Wed, Apr 19, 2017 at 01:28:45PM +0200, Peter Zijlstra wrote:
> > > 
> > > So the thing Maz complained about is because KVM assumes
> > > synchronize_srcu() is 'free' when there is no srcu_read_lock() activity.
> > > This series 'breaks' that.
> > > 
> > > I've not looked hard enough at the new SRCU to see if its possible to
> > > re-instate that feature.
> > 
> > And with the fix I gave Maz, the parallelized version is near enough
> > to being free as well.  It was just a stupid bug on my part: I forgot
> > to check for expedited when scheduling callbacks.
> 
> Right, although for the old SRCU it was true for !expedited as well.

Which is all good fun until someone does a call_srcu() on each and
every munmap() syscall.  ;-)

> Just turns out the KVM memslots crud already uses
> synchronize_srcu_expedited().
> 
> <rant>without a friggin' comment; hate @expedited</rant>

And I won't even try defend the old try_stop_cpus()-based expedited
algorithm in today's context, even if it did seem to be a good idea
at the time.  That said, back at that time, the expectation was that
expedited grace periods would only be used for very rare boot-time
configuration changes, at which time who cares?  But there are a lot
more expedited use cases these days, so the implementation had to change.

But the current code is much better housebroken.  ;-)

							Thanx, Paul