All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>,
	Jiannan Ouyang <ouyang@cs.pitt.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	Avi Kivity <avi.kivity@gmail.com>, Gleb Natapov <gleb@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Srikar <srikar@linux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
	Chegu Vinod <chegu_vinod@hp.com>,
	"Andrew M. Theurer" <habanero@linux.vnet.ibm.com>,
	Srivatsa Vaddagiri <srivatsa.vaddagiri@gmail.com>,
	Andrew Jones <drjones@redhat.com>, Karen Noel <knoel@redhat.com>
Subject: Re: Preemptable Ticket Spinlock
Date: Tue, 23 Apr 2013 07:12:55 +0530	[thread overview]
Message-ID: <5175E71F.8070307@linux.vnet.ibm.com> (raw)
In-Reply-To: <1366660147.6454.6.camel@laptop>

On 04/23/2013 01:19 AM, Peter Zijlstra wrote:
> On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
>> On 04/22/2013 07:51 AM, Peter Zijlstra wrote:
>>> On Sun, 2013-04-21 at 17:12 -0400, Rik van Riel wrote:
>>>>
>>>> If we always incremented the ticket number by 2 (instead of 1), then
>>>> we could use the lower bit of the ticket number as the spinlock.
>>>
>>> ISTR that paravirt ticket locks already do that and use the lsb to
>>> indicate the unlock needs to perform wakeups.
>>>
>>> Also, since all of this is virt nonsense, shouldn't it live in the
>>> paravirt ticket lock code and leave the native code as is?
>>
>> Sure, but that is still no reason not to have the virt
>> implementation be as fast as possible, and share the same
>> data type as the non-virt implementation.
>
> It has to share the same data-type..
>
>> Also, is it guaranteed that the native spin_lock code has
>> not been called yet before we switch over to the paravirt
>> functions?
>>
>> If the native spin_lock code has been called already at
>> that time, the native code would still need to be modified
>> to increment the ticket number by 2, so we end up with a
>> compatible value in each spin lock's .tickets field, and
>> prevent a deadlock after we switch over to the paravirt
>> variant.
>
> I thought the stuff already made it upstream, but apparently not; the
> lastest posting I'm aware of is here:
>
>    https://lkml.org/lkml/2012/5/2/105
>
> That stuff changes the normal ticket increment as well..
>

pv-ticket spinlock went on hold state, after Avi acked because of:

though on non-PLE, we get a huge advantage, on PLE machine the benefit 
was not as impressive (~10% as you stated in email chain) compared to 
the complexity of the patches.
So Avi suggested to try PLE improvements first, so they are going upstream.

https://lkml.org/lkml/2012/7/18/247
https://lkml.org/lkml/2013/1/22/104
https://lkml.org/lkml/2013/2/6/345 (on the way in kvm tree)

Current status of PV spinlock:
I have the rebased patches of pv spinlocks and experimenting with latest 
kernel.I have
Gleb's irq delivery incorporated into the patch series. But I am 
thinknig whether I can
improve some guest side logic in unlock.
I will probably setup a githup and post the link soon.

  parent reply	other threads:[~2013-04-23  1:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJocwccu5QQyuKRvgNyPSFz2K_rzCW419W9-XdSUYOL7+KqQKg@mail.gmail.com>
2013-04-21 21:12 ` Preemptable Ticket Spinlock Rik van Riel
2013-04-21 23:07   ` Jiannan Ouyang
2013-04-22  5:59     ` Raghavendra K T
2013-04-22 11:51   ` Peter Zijlstra
2013-04-22 12:52     ` Rik van Riel
2013-04-22 19:49       ` Peter Zijlstra
2013-04-22 19:56         ` Rik van Riel
2013-04-22 20:05           ` Jiannan Ouyang
2013-04-22 20:08           ` Peter Zijlstra
2013-04-22 20:32             ` Rik van Riel
2013-04-22 20:44               ` Peter Zijlstra
2013-04-22 20:48                 ` Peter Zijlstra
2013-04-22 20:50                   ` Rik van Riel
2013-04-22 20:50                 ` Jiannan Ouyang
2013-04-22 20:54                   ` Chegu Vinod
2013-04-22 20:46             ` Jiannan Ouyang
2013-04-22 20:49               ` Rik van Riel
2013-04-22 21:01                 ` Peter Zijlstra
2013-04-23  5:03                   ` Raghavendra K T
2013-04-22 20:55               ` Peter Zijlstra
2013-04-22 21:31                 ` Jiannan Ouyang
2013-04-22 23:08                 ` Rik van Riel
2013-04-23  5:57                   ` Gleb Natapov
2013-04-23  1:42         ` Raghavendra K T [this message]
2013-05-30 11:56           ` Raghavendra K T
2013-05-30 20:14             ` Thomas Gleixner
2013-04-22 21:56   ` Andi Kleen
2013-04-22 23:13     ` Rik van Riel
2013-04-22  5:58 ` Raghavendra K T
2013-04-22 16:42   ` Jiannan Ouyang
2013-04-23  1:54     ` Raghavendra K T
2013-04-26 20:10 ` Andrew Theurer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5175E71F.8070307@linux.vnet.ibm.com \
    --to=raghavendra.kt@linux.vnet.ibm.com \
    --cc=avi.kivity@gmail.com \
    --cc=chegu_vinod@hp.com \
    --cc=drjones@redhat.com \
    --cc=gleb@redhat.com \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=knoel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=ouyang@cs.pitt.edu \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=srivatsa.vaddagiri@gmail.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.