Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Wanpeng Li]

2017-11-06 18:10 GMT+08:00 Vitaly Kuznetsov :
> Wanpeng Li  writes:
>
>> 2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov :
>>> Wanpeng Li  writes:
>>>
 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov :
> Changes since v9:
> - Rebase to 4.13-rc3.
> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're 
> no
>   functional dependencies on this patch so the series can go through a 
> different tree
>   (and it actually belongs to x86 if I got Ingo's comment right).
> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, 
> Greg KH]
> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>   hyperv_flush_tlb_others() [Andy Shevchenko]
> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>   reported by kbuild test robot (#include )
> - Add Steven's 'Reviewed-by:' to PATCH9.
>
> Original description:
>
> Hyper-V supports hypercalls for doing local and remote TLB flushing and
> gives its guests hints when using hypercall is preferred. While doing
> hypercalls for local TLB flushes is probably not practical (and is not
> being suggested by modern Hyper-V versions) remote TLB flush with a
> hypercall brings significant improvement.
>
> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
> was creating 32 threads which were doing 10 mmap/munmaps each on some
> big file. Here are the results:
>
> Before:
> # time ./pthread_mmap ./randfile
> real3m33.118s
> user0m3.698s
> sys 3m16.624s
>
> After:
> # time ./pthread_mmap ./randfile
> real2m19.920s
> user0m2.662s
> sys 2m9.948s
>
> This series brings a number of small improvements along the way: fast
> hypercall implementation and using it for event signaling, rep hypercalls
> implementation, hyperv tracing subsystem (which only traces the newly 
> added
> remote TLB flush for now).
>

 Hi Vitaly,

 Could you attach your benchmark? I'm interested in to try the
 implementation in paravirt kvm.

>>>
>>> Oh, this would be cool) I briefly discussed the idea with Radim (one of
>>> KVM maintainers) during the last KVM Forum and he wasn't opposed to the
>>> idea. Need to talk to Paolo too. Good thing is that we have everything
>>
>> I talk with Paolo today and he points this feature to me, so I believe
>> he likes it. :) In addition,
>> https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
>> I search Hypervisor Top Level Functional Specification v5.0b.pdf
>> document but didn't find a section introduce the Hyper-V:
>> paravirtualized remote TLB flushing and hypercall stuff, could you
>> point out?
>>
>
> It's there, search for
> HvFlushVirtualAddressSpace/HvFlushVirtualAddressSpaceEx and
> HvFlushVirtualAddressList/HvFlushVirtualAddressListEx.

Got it, thanks.

Regards,
Wanpeng Li
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Wanpeng Li  writes:

> 2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov :
>> Wanpeng Li  writes:
>>
>>> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov :
 Changes since v9:
 - Rebase to 4.13-rc3.
 - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're 
 no
   functional dependencies on this patch so the series can go through a 
 different tree
   (and it actually belongs to x86 if I got Ingo's comment right).
 - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
 KH]
 - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
   hyperv_flush_tlb_others() [Andy Shevchenko]
 - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
   reported by kbuild test robot (#include )
 - Add Steven's 'Reviewed-by:' to PATCH9.

 Original description:

 Hyper-V supports hypercalls for doing local and remote TLB flushing and
 gives its guests hints when using hypercall is preferred. While doing
 hypercalls for local TLB flushes is probably not practical (and is not
 being suggested by modern Hyper-V versions) remote TLB flush with a
 hypercall brings significant improvement.

 To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
 was creating 32 threads which were doing 10 mmap/munmaps each on some
 big file. Here are the results:

 Before:
 # time ./pthread_mmap ./randfile
 real3m33.118s
 user0m3.698s
 sys 3m16.624s

 After:
 # time ./pthread_mmap ./randfile
 real2m19.920s
 user0m2.662s
 sys 2m9.948s

 This series brings a number of small improvements along the way: fast
 hypercall implementation and using it for event signaling, rep hypercalls
 implementation, hyperv tracing subsystem (which only traces the newly added
 remote TLB flush for now).

>>>
>>> Hi Vitaly,
>>>
>>> Could you attach your benchmark? I'm interested in to try the
>>> implementation in paravirt kvm.
>>>
>>
>> Oh, this would be cool) I briefly discussed the idea with Radim (one of
>> KVM maintainers) during the last KVM Forum and he wasn't opposed to the
>> idea. Need to talk to Paolo too. Good thing is that we have everything
>
> I talk with Paolo today and he points this feature to me, so I believe
> he likes it. :) In addition,
> https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
> I search Hypervisor Top Level Functional Specification v5.0b.pdf
> document but didn't find a section introduce the Hyper-V:
> paravirtualized remote TLB flushing and hypercall stuff, could you
> point out?
>

It's there, search for
HvFlushVirtualAddressSpace/HvFlushVirtualAddressSpaceEx and
HvFlushVirtualAddressList/HvFlushVirtualAddressListEx.

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Wanpeng Li]

2017-11-06 17:14 GMT+08:00 Vitaly Kuznetsov :
> Wanpeng Li  writes:
>
>> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov :
>>> Changes since v9:
>>> - Rebase to 4.13-rc3.
>>> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
>>>   functional dependencies on this patch so the series can go through a 
>>> different tree
>>>   (and it actually belongs to x86 if I got Ingo's comment right).
>>> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
>>> KH]
>>> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>>>   hyperv_flush_tlb_others() [Andy Shevchenko]
>>> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>>>   reported by kbuild test robot (#include )
>>> - Add Steven's 'Reviewed-by:' to PATCH9.
>>>
>>> Original description:
>>>
>>> Hyper-V supports hypercalls for doing local and remote TLB flushing and
>>> gives its guests hints when using hypercall is preferred. While doing
>>> hypercalls for local TLB flushes is probably not practical (and is not
>>> being suggested by modern Hyper-V versions) remote TLB flush with a
>>> hypercall brings significant improvement.
>>>
>>> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
>>> was creating 32 threads which were doing 10 mmap/munmaps each on some
>>> big file. Here are the results:
>>>
>>> Before:
>>> # time ./pthread_mmap ./randfile
>>> real3m33.118s
>>> user0m3.698s
>>> sys 3m16.624s
>>>
>>> After:
>>> # time ./pthread_mmap ./randfile
>>> real2m19.920s
>>> user0m2.662s
>>> sys 2m9.948s
>>>
>>> This series brings a number of small improvements along the way: fast
>>> hypercall implementation and using it for event signaling, rep hypercalls
>>> implementation, hyperv tracing subsystem (which only traces the newly added
>>> remote TLB flush for now).
>>>
>>
>> Hi Vitaly,
>>
>> Could you attach your benchmark? I'm interested in to try the
>> implementation in paravirt kvm.
>>
>
> Oh, this would be cool) I briefly discussed the idea with Radim (one of
> KVM maintainers) during the last KVM Forum and he wasn't opposed to the
> idea. Need to talk to Paolo too. Good thing is that we have everything

I talk with Paolo today and he points this feature to me, so I believe
he likes it. :) In addition,
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/tlfs
I search Hypervisor Top Level Functional Specification v5.0b.pdf
document but didn't find a section introduce the Hyper-V:
paravirtualized remote TLB flushing and hypercall stuff, could you
point out?

Regards,
Wanpeng Li

> in place for guests now (HAVE_RCU_TABLE_FREE is enabled globaly on x86).
>
> Please see the microbenchmark attached. Adjust defines in the beginning
> to match your needs. It is not anything smart, basically just a TLB
> trasher.
>
> In theory, the best result is achived when we're overcommiting the host
> by running multiple vCPUs on each pCPU. In this case PV tlb flush avoids
> touching vCPUs which are not scheduled and avoid the wait on the main
> CPU.
>
> --
>   Vitaly
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Wanpeng Li  writes:

> 2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov :
>> Changes since v9:
>> - Rebase to 4.13-rc3.
>> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
>>   functional dependencies on this patch so the series can go through a 
>> different tree
>>   (and it actually belongs to x86 if I got Ingo's comment right).
>> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
>> KH]
>> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>>   hyperv_flush_tlb_others() [Andy Shevchenko]
>> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>>   reported by kbuild test robot (#include )
>> - Add Steven's 'Reviewed-by:' to PATCH9.
>>
>> Original description:
>>
>> Hyper-V supports hypercalls for doing local and remote TLB flushing and
>> gives its guests hints when using hypercall is preferred. While doing
>> hypercalls for local TLB flushes is probably not practical (and is not
>> being suggested by modern Hyper-V versions) remote TLB flush with a
>> hypercall brings significant improvement.
>>
>> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
>> was creating 32 threads which were doing 10 mmap/munmaps each on some
>> big file. Here are the results:
>>
>> Before:
>> # time ./pthread_mmap ./randfile
>> real3m33.118s
>> user0m3.698s
>> sys 3m16.624s
>>
>> After:
>> # time ./pthread_mmap ./randfile
>> real2m19.920s
>> user0m2.662s
>> sys 2m9.948s
>>
>> This series brings a number of small improvements along the way: fast
>> hypercall implementation and using it for event signaling, rep hypercalls
>> implementation, hyperv tracing subsystem (which only traces the newly added
>> remote TLB flush for now).
>>
>
> Hi Vitaly,
>
> Could you attach your benchmark? I'm interested in to try the
> implementation in paravirt kvm.
>

Oh, this would be cool) I briefly discussed the idea with Radim (one of
KVM maintainers) during the last KVM Forum and he wasn't opposed to the
idea. Need to talk to Paolo too. Good thing is that we have everything
in place for guests now (HAVE_RCU_TABLE_FREE is enabled globaly on x86).

Please see the microbenchmark attached. Adjust defines in the beginning
to match your needs. It is not anything smart, basically just a TLB
trasher.

In theory, the best result is achived when we're overcommiting the host
by running multiple vCPUs on each pCPU. In this case PV tlb flush avoids
touching vCPUs which are not scheduled and avoid the wait on the main
CPU.

-- 
  Vitaly

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define nthreads 48
#define pagecount 16384
#define nrounds 1000
#define nchunks 20
#define PAGE_SIZE 4096

int fd;
unsigned long v;

void *threadf(void *ptr)
{
unsigned long *addr[nchunks];
int i, j, k;
struct timespec ts = {0};
int ret;

ts.tv_nsec = random() % 1024;

for (j = 0; j < nrounds; j++) {
for (i = 0; i < nchunks; i++) {
addr[i] = mmap(NULL, PAGE_SIZE * pagecount, PROT_READ, 
MAP_SHARED, fd, i * PAGE_SIZE);
if (addr[i] == MAP_FAILED) {
fprintf(stderr, "mmap\n");
exit(1);
}
}

nanosleep(, NULL);

for (i = 0; i < nchunks; i++) {
v += *addr[i];
}


nanosleep(, NULL);

for (i = 0; i < nchunks; i++) {
munmap(addr[i], PAGE_SIZE * pagecount);
}
}
}

int main(int argc, char *argv[]) {
pthread_t thr[nthreads];
int i;

srandom(time(NULL));

if (argc < 2) {
fprintf(stderr, "usage: %s \n", argv[0]);
exit(1);
}

fd = open(argv[1], O_RDONLY);
if (fd < 0) {
fprintf(stderr, "open\n");
exit(1);
}

for (i = 0; i < nthreads; i++) {
if(pthread_create([i], NULL, threadf, NULL)) {
fprintf(stderr, "pthread_create\n");
exit(1);
}
}

for (i = 0; i < nthreads; i++) {
if(pthread_join(thr[i], NULL)) {
fprintf(stderr, "pthread_join\n");
exit(1);
}
}

return 0;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Wanpeng Li]

2017-08-03 0:09 GMT+08:00 Vitaly Kuznetsov :
> Changes since v9:
> - Rebase to 4.13-rc3.
> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
>   functional dependencies on this patch so the series can go through a 
> different tree
>   (and it actually belongs to x86 if I got Ingo's comment right).
> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg KH]
> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>   hyperv_flush_tlb_others() [Andy Shevchenko]
> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>   reported by kbuild test robot (#include )
> - Add Steven's 'Reviewed-by:' to PATCH9.
>
> Original description:
>
> Hyper-V supports hypercalls for doing local and remote TLB flushing and
> gives its guests hints when using hypercall is preferred. While doing
> hypercalls for local TLB flushes is probably not practical (and is not
> being suggested by modern Hyper-V versions) remote TLB flush with a
> hypercall brings significant improvement.
>
> To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
> was creating 32 threads which were doing 10 mmap/munmaps each on some
> big file. Here are the results:
>
> Before:
> # time ./pthread_mmap ./randfile
> real3m33.118s
> user0m3.698s
> sys 3m16.624s
>
> After:
> # time ./pthread_mmap ./randfile
> real2m19.920s
> user0m2.662s
> sys 2m9.948s
>
> This series brings a number of small improvements along the way: fast
> hypercall implementation and using it for event signaling, rep hypercalls
> implementation, hyperv tracing subsystem (which only traces the newly added
> remote TLB flush for now).
>

Hi Vitaly,

Could you attach your benchmark? I'm interested in to try the
implementation in paravirt kvm.

Regards,
Wanpeng Li
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov  wrote:

> Ingo Molnar  writes:
> 
> > * Vitaly Kuznetsov  wrote:
> >
> >> > Changes since v9:
> >> > - Rebase to 4.13-rc3.
> >> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. 
> >> > There're no
> >> >   functional dependencies on this patch so the series can go through a 
> >> > different tree
> >> >   (and it actually belongs to x86 if I got Ingo's comment right).
> >> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, 
> >> > Greg KH]
> >> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> >> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >> >   reported by kbuild test robot (#include )
> >> > - Add Steven's 'Reviewed-by:' to PATCH9.
> >> 
> >> Ingo,
> >> 
> >> this series ended up being 'almost merged' - you merged all but the last
> >> two patches to 'x86/platform' branch when Peter reported an issue with
> >> pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
> >> freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
> >> resolved and we can hopefully proceed with this series. Could you please
> >> let me know if I need to resend these last two patches or if you can
> >> take them from v10?
> >
> > Ok, I have merged tip:x86/mm into tip:x86/platform to pick up the 
> > dependency and 
> > have applied patches #9 and #10.
> 
> Hope you meant '#8 and #9' as v10 had only 9 patches :-)

Yes ;-)

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Ingo Molnar  writes:

> * Vitaly Kuznetsov  wrote:
>
>> > Changes since v9:
>> > - Rebase to 4.13-rc3.
>> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're 
>> > no
>> >   functional dependencies on this patch so the series can go through a 
>> > different tree
>> >   (and it actually belongs to x86 if I got Ingo's comment right).
>> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
>> > KH]
>> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>> >   hyperv_flush_tlb_others() [Andy Shevchenko]
>> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>> >   reported by kbuild test robot (#include )
>> > - Add Steven's 'Reviewed-by:' to PATCH9.
>> 
>> Ingo,
>> 
>> this series ended up being 'almost merged' - you merged all but the last
>> two patches to 'x86/platform' branch when Peter reported an issue with
>> pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
>> freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
>> resolved and we can hopefully proceed with this series. Could you please
>> let me know if I need to resend these last two patches or if you can
>> take them from v10?
>
> Ok, I have merged tip:x86/mm into tip:x86/platform to pick up the dependency 
> and 
> have applied patches #9 and #10.

Hope you meant '#8 and #9' as v10 had only 9 patches :-)

> Will push it all out after testing.
>

Thanks!

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov  wrote:

> > Changes since v9:
> > - Rebase to 4.13-rc3.
> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
> >   functional dependencies on this patch so the series can go through a 
> > different tree
> >   (and it actually belongs to x86 if I got Ingo's comment right).
> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
> > KH]
> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >   reported by kbuild test robot (#include )
> > - Add Steven's 'Reviewed-by:' to PATCH9.
> 
> Ingo,
> 
> this series ended up being 'almost merged' - you merged all but the last
> two patches to 'x86/platform' branch when Peter reported an issue with
> pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
> freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
> resolved and we can hopefully proceed with this series. Could you please
> let me know if I need to resend these last two patches or if you can
> take them from v10?

Ok, I have merged tip:x86/mm into tip:x86/platform to pick up the dependency 
and 
have applied patches #9 and #10. Will push it all out after testing.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Vitaly Kuznetsov  writes:

> Changes since v9:
> - Rebase to 4.13-rc3.
> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
>   functional dependencies on this patch so the series can go through a 
> different tree
>   (and it actually belongs to x86 if I got Ingo's comment right).
> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg KH]
> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>   hyperv_flush_tlb_others() [Andy Shevchenko]
> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>   reported by kbuild test robot (#include )
> - Add Steven's 'Reviewed-by:' to PATCH9.

Ingo,

this series ended up being 'almost merged' - you merged all but the last
two patches to 'x86/platform' branch when Peter reported an issue with
pagetable walkers. Now as we have 'x86/mm: Enable RCU based page table
freeing (CONFIG_HAVE_RCU_TABLE_FREE=y)' merged to 'x86/mm' this is
resolved and we can hopefully proceed with this series. Could you please
let me know if I need to resend these last two patches or if you can
take them from v10?

Thanks,

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Ingo Molnar  writes:

> I'm getting this build failure with this series:
>
> arch/x86/hyperv/mmu.c: In function ‘hyperv_setup_mmu_ops’:
> arch/x86/hyperv/mmu.c:256:3: error: ‘pv_mmu_ops’ undeclared (first use in 
> this 
> function)
>pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
>^
>
> with the attached (rand-)config.
>

> # CONFIG_PARAVIRT is not set

Ouch, this is definitely required for the new feature. Sorry :-(

I think the best way to handle this (and having in mind upcoming PV
spinlocks for Hyper-V) is something like

diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index c29cd5387a35..50b89ea0e60f 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -3,6 +3,7 @@ menu "Microsoft Hyper-V guest support"
 config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on X86 && ACPI && PCI && X86_LOCAL_APIC && HYPERVISOR_GUEST
+   select PARAVIRT
help
  Select this option to run Linux as a Hyper-V client operating
  system.

added to PATCH7 of the series. In case nobody objects, would you like me
to resend the patch or do the whole v11 submission?

Thanks and sorry for the breakage,

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Ingo Molnar  writes:

> * Vitaly Kuznetsov  wrote:
>
>> Vitaly Kuznetsov  writes:
>> 
>> > Changes since v9:
>> > - Rebase to 4.13-rc3.
>> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're 
>> > no
>> >   functional dependencies on this patch so the series can go through a 
>> > different tree
>> >   (and it actually belongs to x86 if I got Ingo's comment right).
>> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
>> > KH]
>> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>> >   hyperv_flush_tlb_others() [Andy Shevchenko]
>> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>> >   reported by kbuild test robot (#include )
>> > - Add Steven's 'Reviewed-by:' to PATCH9.
>> 
>> Thomas, Ingo, Greg,
>> 
>> do I get it right that the intention is to take this series through x86
>> tree? (See: https://www.spinics.net/lists/kernel/msg2561174.html) If so,
>> is there anything else I need to do to get it accepted?
>
> Yeah, the patches are arch/x86/-heavy, so that would be the ideal workflow - 
> it's 
> just that the series coincided with x86 maintainers vacation time!
>
> I've picked them up now into tip:x86/platform (they look good to me) and will 
> push 
> them out after some testing.
>

Great, thanks!

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Ingo Molnar]

* Vitaly Kuznetsov  wrote:

> Vitaly Kuznetsov  writes:
> 
> > Changes since v9:
> > - Rebase to 4.13-rc3.
> > - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
> >   functional dependencies on this patch so the series can go through a 
> > different tree
> >   (and it actually belongs to x86 if I got Ingo's comment right).
> > - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg 
> > KH]
> > - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
> >   hyperv_flush_tlb_others() [Andy Shevchenko]
> > - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
> >   reported by kbuild test robot (#include )
> > - Add Steven's 'Reviewed-by:' to PATCH9.
> 
> Thomas, Ingo, Greg,
> 
> do I get it right that the intention is to take this series through x86
> tree? (See: https://www.spinics.net/lists/kernel/msg2561174.html) If so,
> is there anything else I need to do to get it accepted?

Yeah, the patches are arch/x86/-heavy, so that would be the ideal workflow - 
it's 
just that the series coincided with x86 maintainers vacation time!

I've picked them up now into tip:x86/platform (they look good to me) and will 
push 
them out after some testing.

Thanks,

Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Vitaly Kuznetsov  writes:

> Changes since v9:
> - Rebase to 4.13-rc3.
> - Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
>   functional dependencies on this patch so the series can go through a 
> different tree
>   (and it actually belongs to x86 if I got Ingo's comment right).
> - Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg KH]
> - A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
>   hyperv_flush_tlb_others() [Andy Shevchenko]
> - Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
>   reported by kbuild test robot (#include )
> - Add Steven's 'Reviewed-by:' to PATCH9.

Thomas, Ingo, Greg,

do I get it right that the intention is to take this series through x86
tree? (See: https://www.spinics.net/lists/kernel/msg2561174.html) If so,
is there anything else I need to do to get it accepted?

Thanks,

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v10 0/9] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

[Vitaly Kuznetsov]

Changes since v9:
- Rebase to 4.13-rc3.
- Drop PATCH1 as it was already taken by Greg to char-misc tree. There're no
  functional dependencies on this patch so the series can go through a 
different tree
  (and it actually belongs to x86 if I got Ingo's comment right).
- Add in missing void return type in PATCH1 [Colin King, Ingo Molnar, Greg KH]
- A few minor fixes in what is now PATCH7: add pr_fmt, tiny style fix in
  hyperv_flush_tlb_others() [Andy Shevchenko]
- Fix "error: implicit declaration of function 'virt_to_phys'" in PATCH2
  reported by kbuild test robot (#include )
- Add Steven's 'Reviewed-by:' to PATCH9.

Original description:

Hyper-V supports hypercalls for doing local and remote TLB flushing and
gives its guests hints when using hypercall is preferred. While doing
hypercalls for local TLB flushes is probably not practical (and is not
being suggested by modern Hyper-V versions) remote TLB flush with a
hypercall brings significant improvement.

To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
was creating 32 threads which were doing 10 mmap/munmaps each on some
big file. Here are the results:

Before:
# time ./pthread_mmap ./randfile 
real3m33.118s
user0m3.698s
sys 3m16.624s

After:
# time ./pthread_mmap ./randfile 
real2m19.920s
user0m2.662s
sys 2m9.948s

This series brings a number of small improvements along the way: fast
hypercall implementation and using it for event signaling, rep hypercalls
implementation, hyperv tracing subsystem (which only traces the newly added
remote TLB flush for now).

Vitaly Kuznetsov (9):
  x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
  x86/hyper-v: make hv_do_hypercall() inline
  x86/hyper-v: fast hypercall implementation
  hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
  x86/hyper-v: implement rep hypercalls
  hyper-v: globalize vp_index
  x86/hyper-v: use hypercall for remote TLB flush
  x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
  tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

 MAINTAINERS |   1 +
 arch/x86/Kbuild |   2 +-
 arch/x86/hyperv/Makefile|   2 +-
 arch/x86/hyperv/hv_init.c   |  90 ++--
 arch/x86/hyperv/mmu.c   | 272 
 arch/x86/include/asm/mshyperv.h | 147 ++-
 arch/x86/include/asm/trace/hyperv.h |  40 ++
 arch/x86/include/uapi/asm/hyperv.h  |  17 +++
 arch/x86/kernel/cpu/mshyperv.c  |   1 +
 drivers/hv/channel_mgmt.c   |  20 +--
 drivers/hv/connection.c |   7 +-
 drivers/hv/hv.c |   9 --
 drivers/hv/hyperv_vmbus.h   |  11 --
 drivers/hv/vmbus_drv.c  |  17 ---
 drivers/pci/host/pci-hyperv.c   |  54 +--
 include/linux/hyperv.h  |  17 +--
 16 files changed, 533 insertions(+), 174 deletions(-)
 create mode 100644 arch/x86/hyperv/mmu.c
 create mode 100644 arch/x86/include/asm/trace/hyperv.h

-- 
2.13.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel