On a VM with only 1 vCPU, the locking fast paths will always be
successful. In this case, there is no need to use the the PV qspinlock
code which has higher overhead on the unlock side than the native
qspinlock code.
Signed-off-by: Waiman Long
---
arch/x86/xen/spinlock.c | 3 ++-
1 file changed
On 07/19/2018 03:18 PM, Boris Ostrovsky wrote:
> On 07/19/2018 09:48 AM, Waiman Long wrote:
>> On a VM with only 1 vCPU, the locking fast paths will always be
>> successful. In this case, there is no need to use the the PV qspinlock
>> code which has higher overhead on the
unneeded pvqspinlock initialization in xen_init_lock_cpu()
which is run after xen_init_spinlocks().
Signed-off-by: Waiman Long
---
arch/x86/xen/spinlock.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index cd97a62..973f10e 100644
--- a/arch
On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
> On Thu, 19 Jul 2018, Waiman Long wrote:
>
>> On a VM with only 1 vCPU, the locking fast paths will always be
>> successful. In this case, there is no need to use the the PV qspinlock
>> code which has higher overhead on
On 07/22/2018 11:31 PM, Wanpeng Li wrote:
> On Fri, 20 Jul 2018 at 06:03, Waiman Long wrote:
>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
>>> On Thu, 19 Jul 2018, Waiman Long wrote:
>>>
>>>> On a VM with only 1 vCPU, the locking fast paths will always
On 07/23/2018 12:42 AM, Davidlohr Bueso wrote:
> On Mon, 23 Jul 2018, Wanpeng Li wrote:
>
>> On Fri, 20 Jul 2018 at 06:03, Waiman Long wrote:
>>>
>>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
>>> > On Thu, 19 Jul 2018, Waiman Long wrote:
>>
RT_SYMBOL(queued_spin_lock_slowpath);
#include "qspinlock_paravirt.h"
#include "qspinlock.c"
-bool nopvspin __initdata;
+bool nopvspin;
static __init int parse_nopvspin(char *arg)
{
nopvspin = true;
Acked-by: Waiman Long
