Linux Virtualization - Jul 2014 - [RFC PATCH v2] Implement Batched (group) ticket lock

On 07/01/2014 01:35 PM, Peter Zijlstra wrote:
> On Sat, Jun 28, 2014 at 02:47:04PM +0530, Raghavendra K T wrote:
>> In virtualized environment there are mainly three problems
>> related to spinlocks that affects performance.
>> 1. LHP (lock holder preemption)
>> 2. Lock Waiter Preemption (LWP)
>> 3. Starvation/fairness
>>
>> Though Ticketlocks solve fairness problem it worsens LWP, LHP problems.
Though
>> pv-ticketlocks tried to address these problems we can further improve
at the
>>   cost of relaxed fairness. The following patch tries to achieve that
by grouping
>> (batched) ticketlocks.
>
> And here I stop reading and ignore this patch, right?
>
> Why should I look at this?
>
For baremetal we continue to have 'fully fair ticketlock' with this 
patch series.

Good thing about the patch is we do have upper bound on starvation and
at the same time we solve Lock Waiter Preemption horror of strict
serialization of ticketlocks in guest and combine definite advantages
of unfair locks for guest.

On Tue, Jul 01, 2014 at 03:14:09PM +0530, Raghavendra K T
wrote:
> On 07/01/2014 01:35 PM, Peter Zijlstra wrote:
> >On Sat, Jun 28, 2014 at 02:47:04PM +0530, Raghavendra K T wrote:
> >>In virtualized environment there are mainly three problems
> >>related to spinlocks that affects performance.
> >>1. LHP (lock holder preemption)
> >>2. Lock Waiter Preemption (LWP)
> >>3. Starvation/fairness
> >>
> >>Though Ticketlocks solve fairness problem it worsens LWP, LHP
problems. Though
> >>pv-ticketlocks tried to address these problems we can further
improve at the
> >>  cost of relaxed fairness. The following patch tries to achieve
that by grouping
> >>(batched) ticketlocks.
> >
> >And here I stop reading and ignore this patch, right?
> >
> >Why should I look at this?
> >
> 
> For baremetal we continue to have 'fully fair ticketlock' with this
patch
> series.
> 
But but but, we're looking at removing ticket locks. So why do we want
to invest in them now?

>>
>> For baremetal we continue to have 'fully fair ticketlock' with
this patch
>> series.
>>
>
> But but but, we're looking at removing ticket locks. So why do we want
> to invest in them now?
>
I have nothing against qspinlock. I am happy to test it/add any bit to 
it if I could.

With this patch we get excellent performance for guest with the
unmodified kernel without affecting host.

My test on guest with batch_size =16,32 showed even better performance
               bs=16      bs=32
  ebizzy_0.5x   0.14       0.90
  ebizzy_1.0x   3.57       7.52
  ebizzy_1.5x  58.97      67.65
  ebizzy_2.0x 121.55     136.45