From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763684AbdDSN0B (ORCPT ); Wed, 19 Apr 2017 09:26:01 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:43032 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1763549AbdDSNZ7 (ORCPT ); Wed, 19 Apr 2017 09:25:59 -0400 Subject: Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 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> <20170419132213.GA17362@linux.vnet.ibm.com> Cc: Peter Zijlstra , 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 From: Christian Borntraeger Date: Wed, 19 Apr 2017 15:25:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170419132213.GA17362@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17041913-8235-0000-0000-00000B567767 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006938; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00849612; UDB=6.00419541; IPR=6.00628245; 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.00015094; XFM=3.00000013; UTC=2017-04-19 13:25:56 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041913-8236-0000-0000-00003B433100 Message-Id: <78aa8cfe-7d7f-d621-75cd-575295e17abd@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-19_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704190118 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/19/2017 03:22 PM, Paul E. McKenney wrote: > On Wed, Apr 19, 2017 at 01:48:08PM +0200, Christian Borntraeger wrote: >> On 04/19/2017 01:28 PM, 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. >> >> Why is such a behaviour change not mentioned in the cover letter? >> I could not find anything in the patch descriptions that would >> indicate a slowdown. How much slower did it get? > > It was an 8x slowdown in boot time of a guest OS running UEFI, from > five seconds to forty seconds. The fix restored the original boot time. > > Why didn't I report the slowdown in my cover letter? Because I didn't > realize that I had created such a stupid bug! ;-) > > Why didn't my testing reveal the bug? Because in my rcutorture testing, > the buggy code runs about as fast as the original, and the fixed new code > runs about an order of magnitude faster. This is because rcutorture's > performance statistics are mostly sensitive to throughput, while Marc's > boot-time run is mostly sensitive to latency. > >> But indeed, there are several places at KVM startup which have been >> reworked to srcu since normal rcu was too slow for several usecases. >> (Mostly registering devices and related data structures at startup, >> basically the qemu/kvm coldplug interaction) > > And here is the patch that restored Marc's boot speed. It simply changes > the original (buggy) fixed delay for no delay in the expedited case and > the same fixed delay in the non-expedited case. > > Thanx, Paul Ok, so it was not a fundamental rework, it was just a bug. Then nevermind :-)