Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Fri, 17 Feb 2017, Andy Lutomirski wrote: > On Fri, Feb 17, 2017 at 2:14 AM, Vitaly Kuznetsov wrote: > > Not only. As far as I understand (and I *think* K. Y. pointed this out) > > when VM is migrating to another host TSC page clocksource is disabled for > > extended period of time so we're better off reading from MSR than > > looping here. With regards to VDSO this means reverting to doing normal > > syscall. > > That's a crappy design. The guest really ought to be able to > distinguish "busy, try again" from "bail and use MSR". > > Thomas, I can see valid reasons why the hypervisor might want to > temporarily disable shared page-based timing, but I think it's silly > that it's conflated with indicating "retry". It's beyond silly if that's the case. > But if this is indeed the ABI, we're stuck with it. No argument. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Fri, Feb 17, 2017 at 2:14 AM, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
>
>> On Wed, 15 Feb 2017, Vitaly Kuznetsov wrote:
>>> Actually, we already have an implementation of TSC page update in KVM
>>> (see arch/x86/kvm/hyperv.c, kvm_hv_setup_tsc_page()) and the update does
>>> the following:
>>>
>>> 0) stash seq into seq_prev
>>> 1) seq = 0 making all reads from the page invalid
>>> 2) smp_wmb()
>>> 3) update tsc_scale, tsc_offset
>>> 4) smp_wmb()
>>> 5) set seq = seq_prev + 1
>>
>> I hope they handle the case where seq_prev overflows and becomes 0 :)
>>
>>> As far as I understand this helps with situations you described above as
>>> guest will notice either invalid value of 0 or seq change. In case the
>>> implementation in real Hyper-V is the same we're safe with compile
>>> barriers only.
>>
>> On x86 that's correct. smp_rmb() resolves to barrier(), but you certainly
>> need the smp_wmb() on the writer side.
>>
>> Now looking at the above your reader side code is bogus:
>>
>> + while (1) {
>> + sequence = tsc_pg->tsc_sequence;
>> + if (!sequence)
>> + break;
>>
>> Why would you break out of the loop when seq is 0? The 0 is just telling
>> you that there is an update in progress.
>
> Not only. As far as I understand (and I *think* K. Y. pointed this out)
> when VM is migrating to another host TSC page clocksource is disabled for
> extended period of time so we're better off reading from MSR than
> looping here. With regards to VDSO this means reverting to doing normal
> syscall.
That's a crappy design. The guest really ought to be able to
distinguish "busy, try again" from "bail and use MSR".
Thomas, I can see valid reasons why the hypervisor might want to
temporarily disable shared page-based timing, but I think it's silly
that it's conflated with indicating "retry".
But if this is indeed the ABI, we're stuck with it.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Fri, 17 Feb 2017, Vitaly Kuznetsov wrote:
> Thomas Gleixner writes:
> > On Wed, 15 Feb 2017, Vitaly Kuznetsov wrote:
> >> Actually, we already have an implementation of TSC page update in KVM
> >> (see arch/x86/kvm/hyperv.c, kvm_hv_setup_tsc_page()) and the update does
> >> the following:
> >>
> >> 0) stash seq into seq_prev
> >> 1) seq = 0 making all reads from the page invalid
> >> 2) smp_wmb()
> >> 3) update tsc_scale, tsc_offset
> >> 4) smp_wmb()
> >> 5) set seq = seq_prev + 1
> >
> > I hope they handle the case where seq_prev overflows and becomes 0 :)
> >
> >> As far as I understand this helps with situations you described above as
> >> guest will notice either invalid value of 0 or seq change. In case the
> >> implementation in real Hyper-V is the same we're safe with compile
> >> barriers only.
> >
> > On x86 that's correct. smp_rmb() resolves to barrier(), but you certainly
> > need the smp_wmb() on the writer side.
> >
> > Now looking at the above your reader side code is bogus:
> >
> > + while (1) {
> > + sequence = tsc_pg->tsc_sequence;
> > + if (!sequence)
> > + break;
> >
> > Why would you break out of the loop when seq is 0? The 0 is just telling
> > you that there is an update in progress.
>
> Not only. As far as I understand (and I *think* K. Y. pointed this out)
> when VM is migrating to another host TSC page clocksource is disabled for
> extended period of time so we're better off reading from MSR than
> looping here. With regards to VDSO this means reverting to doing normal
> syscall.
If you migrate to another host and the VM is using the TSC page, then the
TSC page on the new host _must_ be available and accessible _before_ the VM
resumes there. So that extended period of time does not make any sense at
all. Voodoo programming is the only explanation which come to my mind.
Thanks,
tglx
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
Thomas Gleixner writes:
> On Wed, 15 Feb 2017, Vitaly Kuznetsov wrote:
>> Actually, we already have an implementation of TSC page update in KVM
>> (see arch/x86/kvm/hyperv.c, kvm_hv_setup_tsc_page()) and the update does
>> the following:
>>
>> 0) stash seq into seq_prev
>> 1) seq = 0 making all reads from the page invalid
>> 2) smp_wmb()
>> 3) update tsc_scale, tsc_offset
>> 4) smp_wmb()
>> 5) set seq = seq_prev + 1
>
> I hope they handle the case where seq_prev overflows and becomes 0 :)
>
>> As far as I understand this helps with situations you described above as
>> guest will notice either invalid value of 0 or seq change. In case the
>> implementation in real Hyper-V is the same we're safe with compile
>> barriers only.
>
> On x86 that's correct. smp_rmb() resolves to barrier(), but you certainly
> need the smp_wmb() on the writer side.
>
> Now looking at the above your reader side code is bogus:
>
> + while (1) {
> + sequence = tsc_pg->tsc_sequence;
> + if (!sequence)
> + break;
>
> Why would you break out of the loop when seq is 0? The 0 is just telling
> you that there is an update in progress.
Not only. As far as I understand (and I *think* K. Y. pointed this out)
when VM is migrating to another host TSC page clocksource is disabled for
extended period of time so we're better off reading from MSR than
looping here. With regards to VDSO this means reverting to doing normal
syscall.
>
> The Linux seqcount writer side is:
>
> seq++;
> smp_wmb();
>
> update...
>
> smp_wmb();
> seq++;
>
> and it's defined that an odd sequence count, i.e. bit 0 set means update in
> progress. Which is nice, because you don't have to treat 0 special on the
> writer side and you don't need extra storage to stash seq away :)
>
> So the reader side does:
>
> do {
> while (1) {
>s = READ_ONCE(seq);
>if (!(s & 0x01))
> break;
>cpu_relax();
> }
>smp_rmb();
>
>read data ...
>
>smp_rmb();
>} while (s != seq)
>
> So for that hyperv thing you want:
>
> do {
> while (1) {
>s = READ_ONCE(seq);
>if (s)
> break;
>cpu_relax();
> }
>smp_rmb();
>
>read data ...
>
>smp_rmb();
>} while (s != seq)
>
> Thanks,
>
> tglx
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Wed, 15 Feb 2017, Vitaly Kuznetsov wrote:
> Actually, we already have an implementation of TSC page update in KVM
> (see arch/x86/kvm/hyperv.c, kvm_hv_setup_tsc_page()) and the update does
> the following:
>
> 0) stash seq into seq_prev
> 1) seq = 0 making all reads from the page invalid
> 2) smp_wmb()
> 3) update tsc_scale, tsc_offset
> 4) smp_wmb()
> 5) set seq = seq_prev + 1
I hope they handle the case where seq_prev overflows and becomes 0 :)
> As far as I understand this helps with situations you described above as
> guest will notice either invalid value of 0 or seq change. In case the
> implementation in real Hyper-V is the same we're safe with compile
> barriers only.
On x86 that's correct. smp_rmb() resolves to barrier(), but you certainly
need the smp_wmb() on the writer side.
Now looking at the above your reader side code is bogus:
+ while (1) {
+ sequence = tsc_pg->tsc_sequence;
+ if (!sequence)
+ break;
Why would you break out of the loop when seq is 0? The 0 is just telling
you that there is an update in progress.
The Linux seqcount writer side is:
seq++;
smp_wmb();
update...
smp_wmb();
seq++;
and it's defined that an odd sequence count, i.e. bit 0 set means update in
progress. Which is nice, because you don't have to treat 0 special on the
writer side and you don't need extra storage to stash seq away :)
So the reader side does:
do {
while (1) {
s = READ_ONCE(seq);
if (!(s & 0x01))
break;
cpu_relax();
}
smp_rmb();
read data ...
smp_rmb();
} while (s != seq)
So for that hyperv thing you want:
do {
while (1) {
s = READ_ONCE(seq);
if (s)
break;
cpu_relax();
}
smp_rmb();
read data ...
smp_rmb();
} while (s != seq)
Thanks,
tglx
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
Andy Lutomirski writes: > On Tue, Feb 14, 2017 at 7:50 AM, Vitaly Kuznetsov wrote: >> Thomas Gleixner writes: >> >>> On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: >>> Hi, while we're still waiting for a definitive ACK from Microsoft that the algorithm is good for SMP case (as we can't prevent the code in vdso from migrating between CPUs) I'd like to send v2 with some modifications to keep the discussion going. >>> >>> Migration is irrelevant. The TSC page is guest global so updates will >>> happen on some (random) host CPU and therefor you need the usual barriers >>> like we have them in our seqcounts unless an access to the sequence will >>> trap into the host, which would defeat the whole purpose of the TSC page. >>> >> >> KY Srinivasan writes: >> >>> I checked with the folks on the Hyper-V side and they have confirmed that >>> we need to >>> add memory barriers in the guest code to ensure the various reads from the >>> TSC page are >>> correctly ordered - especially, the initial read of the sequence counter >>> must have acquire >>> semantics. We should ensure that other reads from the TSC page are >>> completed before the >>> second read of the sequence counter. I am working with the Windows team to >>> correctly >>> reflect this algorithm in the Hyper-V specification. >> >> >> Thank you, >> >> do I get it right that combining the above I only need to replace >> virt_rmb() barriers with plain rmb() to get 'lfence' in hv_read_tsc_page >> (PATCH 2)? As members of struct ms_hyperv_tsc_page are volatile we don't >> need READ_ONCE(), compilers are not allowed to merge accesses. The >> resulting code looks good to me: > > No, on multiple counts, unfortunately. > > 1. LFENCE is basically useless except for IO and for (Intel only) > rdtsc_ordered(). AFAIK there is literally no scenario under which > LFENCE is useful for access to normal memory. > Interesting, (For some reason I was under the impression that when I do READ var1 -> reg1 READ var2 -> reg2 from normal memory reads can actually happen in any order and LFENCE in between gives us strict ordering.) But I completely agree it wouldn't help in situations you descibe below: > 2. The problem here has little to do with barriers. You're doing: > > read seq; > read var1; > read var2; > read tsc; > read seq again; > > If the hypervisor updates things between reading var1 and var2 or > between reading var2 and tsc, you aren't guaranteed to notice unless > something fancy is going on regardless of barriers. Similarly, if the > hypervisor starts updating, then you start and finish the whole > function, and then the hypervisor finishes, what guarantees you > notice? > > This really needs a spec from the hypervisor folks as to what's going > on. KVM does this horrible thing in which it sometimes freezes all > vCPUs when updating, for better or for worse. Mostly for worse. If > MS does the same thing, they should document it. ... so I'll have to summon K. Y. again and ask him to use his magic powers to extract some info from the Hyper-V team. As we have TSC page clocksource for quite a while now and no bugs were reported there should be something. Actually, we already have an implementation of TSC page update in KVM (see arch/x86/kvm/hyperv.c, kvm_hv_setup_tsc_page()) and the update does the following: 0) stash seq into seq_prev 1) seq = 0 making all reads from the page invalid 2) smp_wmb() 3) update tsc_scale, tsc_offset 4) smp_wmb() 5) set seq = seq_prev + 1 As far as I understand this helps with situations you described above as guest will notice either invalid value of 0 or seq change. In case the implementation in real Hyper-V is the same we're safe with compile barriers only. > > 3. You need rdtsc_ordered(). Plain RDTSC is not ordered wrt other > memory access, and it can observably screw up as a result. Another interesting thing is if we look at how this is implemented in Windows (see linux.git commit c35b82ef0294) there are no barriers there even for rdtsc... > > Also, Linux tries to avoid volatile variables, so please use READ_ONCE(). > Will do both of the above in my next submission, thanks for the feedback! [snip] -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Tue, Feb 14, 2017 at 7:50 AM, Vitaly Kuznetsov wrote: > Thomas Gleixner writes: > >> On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: >> >>> Hi, >>> >>> while we're still waiting for a definitive ACK from Microsoft that the >>> algorithm is good for SMP case (as we can't prevent the code in vdso from >>> migrating between CPUs) I'd like to send v2 with some modifications to keep >>> the discussion going. >> >> Migration is irrelevant. The TSC page is guest global so updates will >> happen on some (random) host CPU and therefor you need the usual barriers >> like we have them in our seqcounts unless an access to the sequence will >> trap into the host, which would defeat the whole purpose of the TSC page. >> > > KY Srinivasan writes: > >> I checked with the folks on the Hyper-V side and they have confirmed that we >> need to >> add memory barriers in the guest code to ensure the various reads from the >> TSC page are >> correctly ordered - especially, the initial read of the sequence counter >> must have acquire >> semantics. We should ensure that other reads from the TSC page are completed >> before the >> second read of the sequence counter. I am working with the Windows team to >> correctly >> reflect this algorithm in the Hyper-V specification. > > > Thank you, > > do I get it right that combining the above I only need to replace > virt_rmb() barriers with plain rmb() to get 'lfence' in hv_read_tsc_page > (PATCH 2)? As members of struct ms_hyperv_tsc_page are volatile we don't > need READ_ONCE(), compilers are not allowed to merge accesses. The > resulting code looks good to me: No, on multiple counts, unfortunately. 1. LFENCE is basically useless except for IO and for (Intel only) rdtsc_ordered(). AFAIK there is literally no scenario under which LFENCE is useful for access to normal memory. 2. The problem here has little to do with barriers. You're doing: read seq; read var1; read var2; read tsc; read seq again; If the hypervisor updates things between reading var1 and var2 or between reading var2 and tsc, you aren't guaranteed to notice unless something fancy is going on regardless of barriers. Similarly, if the hypervisor starts updating, then you start and finish the whole function, and then the hypervisor finishes, what guarantees you notice? This really needs a spec from the hypervisor folks as to what's going on. KVM does this horrible thing in which it sometimes freezes all vCPUs when updating, for better or for worse. Mostly for worse. If MS does the same thing, they should document it. 3. You need rdtsc_ordered(). Plain RDTSC is not ordered wrt other memory access, and it can observably screw up as a result. Also, Linux tries to avoid volatile variables, so please use READ_ONCE(). > > (gdb) disassemble read_hv_clock_tsc > Dump of assembler code for function read_hv_clock_tsc: >0x8102ca60 <+0>: callq 0x816c7500 <__fentry__> >0x8102ca65 <+5>: mov0xf67974(%rip),%rcx# > 0x81f943e0 >0x8102ca6c <+12>:jmp0x8102ca87 > >0x8102ca6e <+14>:lfence >0x8102ca71 <+17>:mov0x8(%rcx),%r9 >0x8102ca75 <+21>:mov0x10(%rcx),%r8 >0x8102ca79 <+25>:nop >0x8102ca7a <+26>:nop >0x8102ca7b <+27>:nop >0x8102ca7c <+28>:rdtsc >0x8102ca7e <+30>:lfence >0x8102ca81 <+33>:mov(%rcx),%edi >0x8102ca83 <+35>:cmp%edi,%esi >0x8102ca85 <+37>:je 0x8102caa3 > >0x8102ca87 <+39>:mov(%rcx),%esi >0x8102ca89 <+41>:test %esi,%esi >0x8102ca8b <+43>:jne0x8102ca6e > >0x8102ca8d <+45>:push %rbp >0x8102ca8e <+46>:mov$0x4020,%edi >0x8102ca93 <+51>:mov%rsp,%rbp >0x8102ca96 <+54>:and$0xfff0,%rsp >0x8102ca9a <+58>:callq *0x81c36330 >0x8102caa1 <+65>:leaveq >0x8102caa2 <+66>:retq >0x8102caa3 <+67>:shl$0x20,%rdx >0x8102caa7 <+71>:or %rdx,%rax >0x8102caaa <+74>:mul%r9 >0x8102caad <+77>:mov%rdx,%rax >0x8102cab0 <+80>:add%r8,%rax >0x8102cab3 <+83>:cmp$0x,%rax >0x8102cab7 <+87>:je 0x8102ca8d > >0x8102cab9 <+89>:repz retq > End of assembler dump. > > -- > Vitaly -- Andy Lutomirski AMA Capital Management, LLC ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
Thomas Gleixner writes: > On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: > >> Hi, >> >> while we're still waiting for a definitive ACK from Microsoft that the >> algorithm is good for SMP case (as we can't prevent the code in vdso from >> migrating between CPUs) I'd like to send v2 with some modifications to keep >> the discussion going. > > Migration is irrelevant. The TSC page is guest global so updates will > happen on some (random) host CPU and therefor you need the usual barriers > like we have them in our seqcounts unless an access to the sequence will > trap into the host, which would defeat the whole purpose of the TSC page. > KY Srinivasan writes: > I checked with the folks on the Hyper-V side and they have confirmed that we > need to > add memory barriers in the guest code to ensure the various reads from the > TSC page are > correctly ordered - especially, the initial read of the sequence counter must > have acquire > semantics. We should ensure that other reads from the TSC page are completed > before the > second read of the sequence counter. I am working with the Windows team to > correctly > reflect this algorithm in the Hyper-V specification. Thank you, do I get it right that combining the above I only need to replace virt_rmb() barriers with plain rmb() to get 'lfence' in hv_read_tsc_page (PATCH 2)? As members of struct ms_hyperv_tsc_page are volatile we don't need READ_ONCE(), compilers are not allowed to merge accesses. The resulting code looks good to me: (gdb) disassemble read_hv_clock_tsc Dump of assembler code for function read_hv_clock_tsc: 0x8102ca60 <+0>: callq 0x816c7500 <__fentry__> 0x8102ca65 <+5>: mov0xf67974(%rip),%rcx# 0x81f943e0 0x8102ca6c <+12>:jmp0x8102ca87 0x8102ca6e <+14>:lfence 0x8102ca71 <+17>:mov0x8(%rcx),%r9 0x8102ca75 <+21>:mov0x10(%rcx),%r8 0x8102ca79 <+25>:nop 0x8102ca7a <+26>:nop 0x8102ca7b <+27>:nop 0x8102ca7c <+28>:rdtsc 0x8102ca7e <+30>:lfence 0x8102ca81 <+33>:mov(%rcx),%edi 0x8102ca83 <+35>:cmp%edi,%esi 0x8102ca85 <+37>:je 0x8102caa3 0x8102ca87 <+39>:mov(%rcx),%esi 0x8102ca89 <+41>:test %esi,%esi 0x8102ca8b <+43>:jne0x8102ca6e 0x8102ca8d <+45>:push %rbp 0x8102ca8e <+46>:mov$0x4020,%edi 0x8102ca93 <+51>:mov%rsp,%rbp 0x8102ca96 <+54>:and$0xfff0,%rsp 0x8102ca9a <+58>:callq *0x81c36330 0x8102caa1 <+65>:leaveq 0x8102caa2 <+66>:retq 0x8102caa3 <+67>:shl$0x20,%rdx 0x8102caa7 <+71>:or %rdx,%rax 0x8102caaa <+74>:mul%r9 0x8102caad <+77>:mov%rdx,%rax 0x8102cab0 <+80>:add%r8,%rax 0x8102cab3 <+83>:cmp$0x,%rax 0x8102cab7 <+87>:je 0x8102ca8d 0x8102cab9 <+89>:repz retq End of assembler dump. -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
On Tue, 14 Feb 2017, Vitaly Kuznetsov wrote: > Hi, > > while we're still waiting for a definitive ACK from Microsoft that the > algorithm is good for SMP case (as we can't prevent the code in vdso from > migrating between CPUs) I'd like to send v2 with some modifications to keep > the discussion going. Migration is irrelevant. The TSC page is guest global so updates will happen on some (random) host CPU and therefor you need the usual barriers like we have them in our seqcounts unless an access to the sequence will trap into the host, which would defeat the whole purpose of the TSC page. Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, February 14, 2017 4:44 AM > To: x...@kernel.org; Andy Lutomirski > Cc: Thomas Gleixner ; Ingo Molnar ; > H. Peter Anvin ; KY Srinivasan ; > Haiyang Zhang ; Stephen Hemminger > ; Dexuan Cui ; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; > virtualizat...@lists.linux-foundation.org > Subject: [PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support > > Hi, > > while we're still waiting for a definitive ACK from Microsoft that the > algorithm > is good for SMP case (as we can't prevent the code in vdso from migrating > between CPUs) I'd like to send v2 with some modifications to keep the > discussion going. I checked with the folks on the Hyper-V side and they have confirmed that we need to add memory barriers in the guest code to ensure the various reads from the TSC page are correctly ordered - especially, the initial read of the sequence counter must have acquire semantics. We should ensure that other reads from the TSC page are completed before the second read of the sequence counter. I am working with the Windows team to correctly reflect this algorithm in the Hyper-V specification. Regards, K. Y > > Changes since v1: > - Document the TSC page reading protocol [Thomas Gleixner]. > > - Separate the TSC page reading code from read_hv_clock_tsc() and put it to > asm/mshyperv.h to use from both hv_init.c and vdso. > > - Add explicit barriers [Thomas Gleixner] > > Original description: > > Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol > defined by the hypervisor is different from VCLOCK_PVCLOCK. Implemented > the required support. Simple sysbench test shows the following results: > > Before: > # time sysbench --test=memory --max-requests=50 run ... > real1m22.618s > user0m50.193s > sys 0m32.268s > > After: > # time sysbench --test=memory --max-requests=50 run ... > real 0m47.241s > user 0m47.117s > sys 0m0.008s > > Patches 1 and 2 are made on top of K. Y.'s code refactoring which moved tsc > page clocksource to arch/x86/hyperv/hv_init.c, this is currently present in > Greg's char-misc-next tree. > > Vitaly Kuznetsov (3): > x86/hyperv: implement hv_get_tsc_page() > x86/hyperv: move TSC reading method to asm/mshyperv.h > x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method > > arch/x86/entry/vdso/vclock_gettime.c | 24 +++ > arch/x86/entry/vdso/vdso-layout.lds.S | 3 +- > arch/x86/entry/vdso/vdso2c.c | 3 ++ > arch/x86/entry/vdso/vma.c | 7 + > arch/x86/hyperv/hv_init.c | 48 + > arch/x86/include/asm/clocksource.h| 3 +- > arch/x86/include/asm/mshyperv.h | 58 > +++ > arch/x86/include/asm/vdso.h | 1 + > drivers/hv/Kconfig| 3 ++ > 9 files changed, 114 insertions(+), 36 deletions(-) > > -- > 2.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/3] x86/vdso: Add Hyper-V TSC page clocksource support
Hi, while we're still waiting for a definitive ACK from Microsoft that the algorithm is good for SMP case (as we can't prevent the code in vdso from migrating between CPUs) I'd like to send v2 with some modifications to keep the discussion going. Changes since v1: - Document the TSC page reading protocol [Thomas Gleixner]. - Separate the TSC page reading code from read_hv_clock_tsc() and put it to asm/mshyperv.h to use from both hv_init.c and vdso. - Add explicit barriers [Thomas Gleixner] Original description: Hyper-V TSC page clocksource is suitable for vDSO, however, the protocol defined by the hypervisor is different from VCLOCK_PVCLOCK. Implemented the required support. Simple sysbench test shows the following results: Before: # time sysbench --test=memory --max-requests=50 run ... real1m22.618s user0m50.193s sys 0m32.268s After: # time sysbench --test=memory --max-requests=50 run ... real0m47.241s user0m47.117s sys 0m0.008s Patches 1 and 2 are made on top of K. Y.'s code refactoring which moved tsc page clocksource to arch/x86/hyperv/hv_init.c, this is currently present in Greg's char-misc-next tree. Vitaly Kuznetsov (3): x86/hyperv: implement hv_get_tsc_page() x86/hyperv: move TSC reading method to asm/mshyperv.h x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method arch/x86/entry/vdso/vclock_gettime.c | 24 +++ arch/x86/entry/vdso/vdso-layout.lds.S | 3 +- arch/x86/entry/vdso/vdso2c.c | 3 ++ arch/x86/entry/vdso/vma.c | 7 + arch/x86/hyperv/hv_init.c | 48 + arch/x86/include/asm/clocksource.h| 3 +- arch/x86/include/asm/mshyperv.h | 58 +++ arch/x86/include/asm/vdso.h | 1 + drivers/hv/Kconfig| 3 ++ 9 files changed, 114 insertions(+), 36 deletions(-) -- 2.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
