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 :-)
