On 07/18/2018 09:15 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 17, 2018 at 05:59:27PM -0400, Waiman Long wrote:
>> On a VM with only 1 vCPU, the locking fast path will always be
>> successful. In this case, there is no need to use the the PV qspinlock
>> code which has higher overhead on the un
On Tue, Jul 17, 2018 at 05:59:27PM -0400, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast path 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.
Why not make
On 17/07/2018 23:59, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast path 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
>
On a VM with only 1 vCPU, the locking fast path 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/kernel/kvm.c | 4
1 file changed, 4
4 matches
Mail list logo