Messages in this thread | | | Subject | Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12 | From | Marc Zyngier <> | Date | Wed, 19 Apr 2017 13:51:22 +0100 |
| |
On 19/04/17 13:08, Peter Zijlstra 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? >> >> 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) > > I suspect Paul is not considering this a 'normal' RCU feature, and > therefore didn't think about changing this. > > I know I was fairly surprised by this requirement when I ran into it; > and only accidentally remembered it now that maz complained.
The issue I noticed yesterday has been addressed here:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev.2017.04.17a&id=6eec94fe40e294b04d32c8ef552e28fa6159bdad
and was triggered by the constant mapping/unmapping of memslots that QEMU triggers when emulating a NOR flash that UEFI uses for storing its variables.
So far, I'm not seeing any other spectacular regression introduced by this series.
Thanks,
M. -- Jazz is not dead. It just smells funny...
| |