diff mbox

[V12,0/14] Paravirtualized ticket spinlocks

Message ID 52040A05.5080107@zytor.com (mailing list archive)
State New, archived
Headers show

Commit Message

H. Peter Anvin Aug. 8, 2013, 9:13 p.m. UTC
On 08/07/2013 06:02 PM, Gleb Natapov wrote:
> On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
>>> On 08/07/2013 10:18 AM, H. Peter Anvin wrote:
>>>>> Please let me know, if I should rebase again.
>>>>>
>>>>
>>>> tip:master is not a stable branch; it is more like linux-next.  We need
>>>> to figure out which topic branches are dependencies for this set.
>>>
>>> Okay. I 'll start looking at the branches that would get affected.
>>> (Xen, kvm are obvious ones).
>>> Please do let me know the branches I might have to check for.
>>
>> >From the Xen standpoint anything past v3.11-rc4 would work.
>>
> For KVM as early as past v3.11-rc1 would be OK.
> 

I'm still completely confused as to the base of this patchset.  The
first patch has the following hunk for arch/x86/include/asm/paravirt.h:


 {
        PVOP_VCALL2(pv_lock_ops.unlock_kick, lock, ticket);


However, there is no ticket_unlock_kick in paravirt.h in either
tip:master nor in linus...

	-hpa



--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

H. Peter Anvin Aug. 8, 2013, 11:04 p.m. UTC | #1
On 08/08/2013 02:13 PM, H. Peter Anvin wrote:
> On 08/07/2013 06:02 PM, Gleb Natapov wrote:
>> On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
>>>> On 08/07/2013 10:18 AM, H. Peter Anvin wrote:
>>>>>> Please let me know, if I should rebase again.
>>>>>>
>>>>>
>>>>> tip:master is not a stable branch; it is more like linux-next.  We need
>>>>> to figure out which topic branches are dependencies for this set.
>>>>
>>>> Okay. I 'll start looking at the branches that would get affected.
>>>> (Xen, kvm are obvious ones).
>>>> Please do let me know the branches I might have to check for.
>>>
>>> >From the Xen standpoint anything past v3.11-rc4 would work.
>>>
>> For KVM as early as past v3.11-rc1 would be OK.
>>
> 
> I'm still completely confused as to the base of this patchset.  The
> first patch has the following hunk for arch/x86/include/asm/paravirt.h:
> 

Okay, I figured it out.

One of several problems with the formatting of this patchset is that it
has one- and two-digit patch numbers in the headers, which meant that my
scripts tried to apply patch 10 first.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Raghavendra K T Aug. 9, 2013, 12:50 p.m. UTC | #2
On 08/09/2013 04:34 AM, H. Peter Anvin wrote:
>
> Okay, I figured it out.
>
> One of several problems with the formatting of this patchset is that it
> has one- and two-digit patch numbers in the headers, which meant that my
> scripts tried to apply patch 10 first.
>

My bad. I 'll send out in uniform digit form next time.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Konrad Rzeszutek Wilk Aug. 9, 2013, 1 p.m. UTC | #3
On Fri, Aug 09, 2013 at 06:20:02PM +0530, Raghavendra K T wrote:
> On 08/09/2013 04:34 AM, H. Peter Anvin wrote:
> >
> >Okay, I figured it out.
> >
> >One of several problems with the formatting of this patchset is that it
> >has one- and two-digit patch numbers in the headers, which meant that my
> >scripts tried to apply patch 10 first.
> >
> 
> My bad. I 'll send out in uniform digit form next time.
> 

If you use 'git format-patch --subject-prefix "PATCH V14" v3.11-rc4..'
and 'git send-email --subject "[PATCH V14] bla blah" ..'
that should be automatically taken care of?

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Raghavendra K T Aug. 9, 2013, 1:14 p.m. UTC | #4
On 08/09/2013 06:30 PM, Konrad Rzeszutek Wilk wrote:
>> My bad. I 'll send out in uniform digit form next time.
>>
>
> If you use 'git format-patch --subject-prefix "PATCH V14" v3.11-rc4..'
> and 'git send-email --subject "[PATCH V14] bla blah" ..'
> that should be automatically taken care of?
>

Thanks Konrad.
Yes. it should. I am planning to use git send-email instead of custom
script.


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
H. Peter Anvin Aug. 9, 2013, 2:51 p.m. UTC | #5
On 08/09/2013 06:00 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 09, 2013 at 06:20:02PM +0530, Raghavendra K T wrote:
>> On 08/09/2013 04:34 AM, H. Peter Anvin wrote:
>>>
>>> Okay, I figured it out.
>>>
>>> One of several problems with the formatting of this patchset is that it
>>> has one- and two-digit patch numbers in the headers, which meant that my
>>> scripts tried to apply patch 10 first.
>>>
>>
>> My bad. I 'll send out in uniform digit form next time.
>>
> 
> If you use 'git format-patch --subject-prefix "PATCH V14" v3.11-rc4..'
> and 'git send-email --subject "[PATCH V14] bla blah" ..'
> that should be automatically taken care of?
> 

Indeed it should.

Another problem with this patchset was that the subject was duplicated
in the body, which meant the tools didn't pick up the From: line.  I
ended up having to manually edit them.

That seems to have been fixed, too, in V13.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- arch/x86/include/asm/paravirt.h
+++ arch/x86/include/asm/paravirt.h
@@ -718,7 +718,7 @@ 
        PVOP_VCALLEE2(pv_lock_ops.lock_spinning, lock, ticket);
 }

-static __always_inline void ____ticket_unlock_kick(struct arch_spinlock
*lock,
+static __always_inline void __ticket_unlock_kick(struct arch_spinlock
*lock,
                                                        __ticket_t ticket)