[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a322a051-72a8-5beb-8ce5-f0b17c088be6@arm.com>
Date: Wed, 19 Apr 2017 13:51:22 +0100
From: Marc Zyngier <marc.zyngier@....com>
To: Peter Zijlstra <peterz@...radead.org>,
Christian Borntraeger <borntraeger@...ibm.com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH v2 tip/core/rcu 0/13] Miscellaneous fixes for 4.12
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...
Powered by blists - more mailing lists