Re: [PATCH v10 03/19] qspinlock: Add pending bit

From: Waiman Long <waiman.long@hp.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: x86@kernel.org, Gleb Natapov <gleb@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	linux-arch@vger.kernel.org, kvm@vger.kernel.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@redhat.com>,
	xen-devel@lists.xenproject.org,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Scott J Norton <scott.norton@hp.com>,
	Paolo Bonzini <paolo.bonzini@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	virtualization@lists.linux-foundation.org,
	Chegu Vinod <chegu_vinod@hp.com>, Oleg Nesterov <oleg@redhat.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v10 03/19] qspinlock: Add pending bit
Date: Tue, 13 May 2014 15:47:00 -0400	[thread overview]
Message-ID: <537276B4.10209@hp.com> (raw)
In-Reply-To: <20140512152208.GA12309@potion.brq.redhat.com>

On 05/12/2014 11:22 AM, Radim Krčmář wrote:
> 2014-05-07 11:01-0400, Waiman Long:
>> From: Peter Zijlstra<peterz@infradead.org>
>>
>> Because the qspinlock needs to touch a second cacheline; add a pending
>> bit and allow a single in-word spinner before we punt to the second
>> cacheline.
> I think there is an unwanted scenario on virtual machines:
> 1) VCPU sets the pending bit and start spinning.
> 2) Pending VCPU gets descheduled.
>      - we have PLE and lock holder isn't running [1]
>      - the hypervisor randomly preempts us
> 3) Lock holder unlocks while pending VCPU is waiting in queue.
> 4) Subsequent lockers will see free lock with set pending bit and will
>     loop in trylock's 'for (;;)'
>      - the worst-case is lock starving [2]
>      - PLE can save us from wasting whole timeslice
>
> Retry threshold is the easiest solution, regardless of its ugliness [4].

Yes, that can be a real issue. Some sort of retry threshold, as you 
said, should be able to handle it.

BTW, the relevant patch should be 16/19 where the PV spinlock stuff 
should be discussed. This patch is perfectly fine.

> Another minor design flaw is that formerly first VCPU gets appended to
> the tail when it decides to queue;
> is the performance gain worth it?
>
> Thanks.

Yes, the performance gain is worth it. The primary goal is to be not 
worse than ticket spinlock in light load situation which is the most 
common case. This feature is need to achieve that.

-Longman
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization