Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1288019 > unrolled thread

[PATCH 0/5] x86: KVM vdso and clock improvements

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/5] x86: KVM vdso and clock improvements Andy Lutomirski <luto@kernel.org> - 2015-12-10 00:20 +0100
    [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader Andy Lutomirski <luto@kernel.org> - 2015-12-10 00:20 +0100
      Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso  pvclock reader Paolo Bonzini <pbonzini@redhat.com> - 2015-12-10 10:20 +0100
        Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso  pvclock reader Ingo Molnar <mingo@kernel.org> - 2015-12-11 09:00 +0100
          Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso  pvclock reader Paolo Bonzini <pbonzini@redhat.com> - 2015-12-11 09:50 +0100
            Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso  pvclock reader Andy Lutomirski <luto@amacapital.net> - 2015-12-11 19:10 +0100
    Re: [PATCH 0/5] x86: KVM vdso and clock improvements Andy Lutomirski <luto@amacapital.net> - 2015-12-11 04:30 +0100

#1288019 — [PATCH 0/5] x86: KVM vdso and clock improvements

NB: patch 1 doesn't really belong here, but it makes this a lot
easier for me to test.  Patch 1, if it's okay at all, should go
though the kvm tree.  The rest should probably go through
tip:x86/vdso once they're reviewed.

I'll do a followup to enable vdso pvclock on 32-bit guests.
I'm not currently set up to test it.  (The KVM people could also
do it very easily on top of these patches.)

Andy Lutomirski (5):
  x86/kvm: On KVM re-enable (e.g. after suspend), update clocks
  x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
  x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap
  x86/vdso: Remove pvclock fixmap machinery
  x86/vdso: Enable vdso pvclock access on all vdso variants

 arch/x86/entry/vdso/vclock_gettime.c  | 151 ++++++++++++++++------------------
 arch/x86/entry/vdso/vdso-layout.lds.S |   3 +-
 arch/x86/entry/vdso/vdso2c.c          |   3 +
 arch/x86/entry/vdso/vma.c             |  14 ++++
 arch/x86/include/asm/fixmap.h         |   5 --
 arch/x86/include/asm/pvclock.h        |  14 ++--
 arch/x86/include/asm/vdso.h           |   1 +
 arch/x86/kernel/kvmclock.c            |  11 ++-
 arch/x86/kernel/pvclock.c             |  24 ------
 arch/x86/kvm/x86.c                    |  75 +----------------
 10 files changed, 110 insertions(+), 191 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1288020 — [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

From: Andy Lutomirski <luto@amacapital.net>

The pvclock vdso code was too abstracted to understand easily and
excessively paranoid.  Simplify it for a huge speedup.

This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.

Before, vclock_gettime using kvm-clock took about 45ns on my machine.
With this change, it takes 29ns, which is almost as fast as the pure TSC
implementation.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
 arch/x86/entry/vdso/vclock_gettime.c | 81 ++++++++++++++++++++----------------
 1 file changed, 46 insertions(+), 35 deletions(-)

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
index ca94fa649251..c325ba1bdddf 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
 
 static notrace cycle_t vread_pvclock(int *mode)
 {
-	const struct pvclock_vsyscall_time_info *pvti;
+	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
 	cycle_t ret;
-	u64 last;
-	u32 version;
-	u8 flags;
-	unsigned cpu, cpu1;
-
+	u64 tsc, pvti_tsc;
+	u64 last, delta, pvti_system_time;
+	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
 
 	/*
-	 * Note: hypervisor must guarantee that:
-	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
-	 * 2. that per-CPU pvclock time info is updated if the
-	 *    underlying CPU changes.
-	 * 3. that version is increased whenever underlying CPU
-	 *    changes.
+	 * Note: The kernel and hypervisor must guarantee that cpu ID
+	 * number maps 1:1 to per-CPU pvclock time info.
+	 *
+	 * Because the hypervisor is entirely unaware of guest userspace
+	 * preemption, it cannot guarantee that per-CPU pvclock time
+	 * info is updated if the underlying CPU changes or that that
+	 * version is increased whenever underlying CPU changes.
 	 *
+	 * On KVM, we are guaranteed that pvti updates for any vCPU are
+	 * atomic as seen by *all* vCPUs.  This is an even stronger
+	 * guarantee than we get with a normal seqlock.
+	 *
+	 * On Xen, we don't appear to have that guarantee, but Xen still
+	 * supplies a valid seqlock using the version field.
+
+	 * We only do pvclock vdso timing at all if
+	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+	 * mean that all vCPUs have matching pvti and that the TSC is
+	 * synced, so we can just look at vCPU 0's pvti.
 	 */
-	do {
-		cpu = __getcpu() & VGETCPU_CPU_MASK;
-		/* TODO: We can put vcpu id into higher bits of pvti.version.
-		 * This will save a couple of cycles by getting rid of
-		 * __getcpu() calls (Gleb).
-		 */
-
-		pvti = get_pvti(cpu);
-
-		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
-
-		/*
-		 * Test we're still on the cpu as well as the version.
-		 * We could have been migrated just after the first
-		 * vgetcpu but before fetching the version, so we
-		 * wouldn't notice a version change.
-		 */
-		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
-	} while (unlikely(cpu != cpu1 ||
-			  (pvti->pvti.version & 1) ||
-			  pvti->pvti.version != version));
-
-	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
+
+	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
 		*mode = VCLOCK_NONE;
+		return 0;
+	}
+
+	do {
+		version = pvti->version;
+
+		/* This is also a read barrier, so we'll read version first. */
+		tsc = rdtsc_ordered();
+
+		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
+		pvti_tsc_shift = pvti->tsc_shift;
+		pvti_system_time = pvti->system_time;
+		pvti_tsc = pvti->tsc_timestamp;
+
+		/* Make sure that the version double-check is last. */
+		smp_rmb();
+	} while (unlikely((version & 1) || version != pvti->version));
+
+	delta = tsc - pvti_tsc;
+	ret = pvti_system_time +
+		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
+				    pvti_tsc_shift);
 
 	/* refer to tsc.c read_tsc() comment for rationale */
 	last = gtod->cycle_last;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1288379 — Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 10/12/2015 00:12, Andy Lutomirski wrote:
> From: Andy Lutomirski <luto@amacapital.net>
> 
> The pvclock vdso code was too abstracted to understand easily and
> excessively paranoid.  Simplify it for a huge speedup.
> 
> This opens the door for additional simplifications, as the vdso no
> longer accesses the pvti for any vcpu other than vcpu 0.
> 
> Before, vclock_gettime using kvm-clock took about 45ns on my machine.
> With this change, it takes 29ns, which is almost as fast as the pure TSC
> implementation.
> 
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
>  arch/x86/entry/vdso/vclock_gettime.c | 81 ++++++++++++++++++++----------------
>  1 file changed, 46 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
> index ca94fa649251..c325ba1bdddf 100644
> --- a/arch/x86/entry/vdso/vclock_gettime.c
> +++ b/arch/x86/entry/vdso/vclock_gettime.c
> @@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>  
>  static notrace cycle_t vread_pvclock(int *mode)
>  {
> -	const struct pvclock_vsyscall_time_info *pvti;
> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>  	cycle_t ret;
> -	u64 last;
> -	u32 version;
> -	u8 flags;
> -	unsigned cpu, cpu1;
> -
> +	u64 tsc, pvti_tsc;
> +	u64 last, delta, pvti_system_time;
> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>  
>  	/*
> -	 * Note: hypervisor must guarantee that:
> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> -	 * 2. that per-CPU pvclock time info is updated if the
> -	 *    underlying CPU changes.
> -	 * 3. that version is increased whenever underlying CPU
> -	 *    changes.
> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> +	 * number maps 1:1 to per-CPU pvclock time info.
> +	 *
> +	 * Because the hypervisor is entirely unaware of guest userspace
> +	 * preemption, it cannot guarantee that per-CPU pvclock time
> +	 * info is updated if the underlying CPU changes or that that
> +	 * version is increased whenever underlying CPU changes.
>  	 *
> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> +	 * guarantee than we get with a normal seqlock.
> +	 *
> +	 * On Xen, we don't appear to have that guarantee, but Xen still
> +	 * supplies a valid seqlock using the version field.
> +
> +	 * We only do pvclock vdso timing at all if
> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> +	 * mean that all vCPUs have matching pvti and that the TSC is
> +	 * synced, so we can just look at vCPU 0's pvti.
>  	 */
> -	do {
> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> -		 * This will save a couple of cycles by getting rid of
> -		 * __getcpu() calls (Gleb).
> -		 */
> -
> -		pvti = get_pvti(cpu);
> -
> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> -
> -		/*
> -		 * Test we're still on the cpu as well as the version.
> -		 * We could have been migrated just after the first
> -		 * vgetcpu but before fetching the version, so we
> -		 * wouldn't notice a version change.
> -		 */
> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> -	} while (unlikely(cpu != cpu1 ||
> -			  (pvti->pvti.version & 1) ||
> -			  pvti->pvti.version != version));
> -
> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> +
> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>  		*mode = VCLOCK_NONE;
> +		return 0;
> +	}
> +
> +	do {
> +		version = pvti->version;
> +
> +		/* This is also a read barrier, so we'll read version first. */
> +		tsc = rdtsc_ordered();
> +
> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> +		pvti_tsc_shift = pvti->tsc_shift;
> +		pvti_system_time = pvti->system_time;
> +		pvti_tsc = pvti->tsc_timestamp;
> +
> +		/* Make sure that the version double-check is last. */
> +		smp_rmb();
> +	} while (unlikely((version & 1) || version != pvti->version));
> +
> +	delta = tsc - pvti_tsc;
> +	ret = pvti_system_time +
> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> +				    pvti_tsc_shift);
>  
>  	/* refer to tsc.c read_tsc() comment for rationale */
>  	last = gtod->cycle_last;
> 

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289282 — Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

* Paolo Bonzini <pbonzini@redhat.com> wrote:

> 
> 
> On 10/12/2015 00:12, Andy Lutomirski wrote:
> > From: Andy Lutomirski <luto@amacapital.net>
> > 
> > The pvclock vdso code was too abstracted to understand easily and
> > excessively paranoid.  Simplify it for a huge speedup.
> > 
> > This opens the door for additional simplifications, as the vdso no
> > longer accesses the pvti for any vcpu other than vcpu 0.
> > 
> > Before, vclock_gettime using kvm-clock took about 45ns on my machine.
> > With this change, it takes 29ns, which is almost as fast as the pure TSC
> > implementation.
> > 
> > Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> > ---
> >  arch/x86/entry/vdso/vclock_gettime.c | 81 ++++++++++++++++++++----------------
> >  1 file changed, 46 insertions(+), 35 deletions(-)
> > 
> > diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
> > index ca94fa649251..c325ba1bdddf 100644
> > --- a/arch/x86/entry/vdso/vclock_gettime.c
> > +++ b/arch/x86/entry/vdso/vclock_gettime.c
> > @@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
> >  
> >  static notrace cycle_t vread_pvclock(int *mode)
> >  {
> > -	const struct pvclock_vsyscall_time_info *pvti;
> > +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
> >  	cycle_t ret;
> > -	u64 last;
> > -	u32 version;
> > -	u8 flags;
> > -	unsigned cpu, cpu1;
> > -
> > +	u64 tsc, pvti_tsc;
> > +	u64 last, delta, pvti_system_time;
> > +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
> >  
> >  	/*
> > -	 * Note: hypervisor must guarantee that:
> > -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
> > -	 * 2. that per-CPU pvclock time info is updated if the
> > -	 *    underlying CPU changes.
> > -	 * 3. that version is increased whenever underlying CPU
> > -	 *    changes.
> > +	 * Note: The kernel and hypervisor must guarantee that cpu ID
> > +	 * number maps 1:1 to per-CPU pvclock time info.
> > +	 *
> > +	 * Because the hypervisor is entirely unaware of guest userspace
> > +	 * preemption, it cannot guarantee that per-CPU pvclock time
> > +	 * info is updated if the underlying CPU changes or that that
> > +	 * version is increased whenever underlying CPU changes.
> >  	 *
> > +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
> > +	 * atomic as seen by *all* vCPUs.  This is an even stronger
> > +	 * guarantee than we get with a normal seqlock.
> > +	 *
> > +	 * On Xen, we don't appear to have that guarantee, but Xen still
> > +	 * supplies a valid seqlock using the version field.
> > +
> > +	 * We only do pvclock vdso timing at all if
> > +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
> > +	 * mean that all vCPUs have matching pvti and that the TSC is
> > +	 * synced, so we can just look at vCPU 0's pvti.
> >  	 */
> > -	do {
> > -		cpu = __getcpu() & VGETCPU_CPU_MASK;
> > -		/* TODO: We can put vcpu id into higher bits of pvti.version.
> > -		 * This will save a couple of cycles by getting rid of
> > -		 * __getcpu() calls (Gleb).
> > -		 */
> > -
> > -		pvti = get_pvti(cpu);
> > -
> > -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
> > -
> > -		/*
> > -		 * Test we're still on the cpu as well as the version.
> > -		 * We could have been migrated just after the first
> > -		 * vgetcpu but before fetching the version, so we
> > -		 * wouldn't notice a version change.
> > -		 */
> > -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
> > -	} while (unlikely(cpu != cpu1 ||
> > -			  (pvti->pvti.version & 1) ||
> > -			  pvti->pvti.version != version));
> > -
> > -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> > +
> > +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
> >  		*mode = VCLOCK_NONE;
> > +		return 0;
> > +	}
> > +
> > +	do {
> > +		version = pvti->version;
> > +
> > +		/* This is also a read barrier, so we'll read version first. */
> > +		tsc = rdtsc_ordered();
> > +
> > +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
> > +		pvti_tsc_shift = pvti->tsc_shift;
> > +		pvti_system_time = pvti->system_time;
> > +		pvti_tsc = pvti->tsc_timestamp;
> > +
> > +		/* Make sure that the version double-check is last. */
> > +		smp_rmb();
> > +	} while (unlikely((version & 1) || version != pvti->version));
> > +
> > +	delta = tsc - pvti_tsc;
> > +	ret = pvti_system_time +
> > +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
> > +				    pvti_tsc_shift);
> >  
> >  	/* refer to tsc.c read_tsc() comment for rationale */
> >  	last = gtod->cycle_last;
> > 
> 
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Thanks. I've added your Reviewed-by to the 1/5 patch as well - to be able to put 
the whole series into the tip:x86/entry tree. Let me know if you'd like it to be 
done differently.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289333 — Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 11/12/2015 08:52, Ingo Molnar wrote:
> 
> * Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>>
>>
>> On 10/12/2015 00:12, Andy Lutomirski wrote:
>>> From: Andy Lutomirski <luto@amacapital.net>
>>>
>>> The pvclock vdso code was too abstracted to understand easily and
>>> excessively paranoid.  Simplify it for a huge speedup.
>>>
>>> This opens the door for additional simplifications, as the vdso no
>>> longer accesses the pvti for any vcpu other than vcpu 0.
>>>
>>> Before, vclock_gettime using kvm-clock took about 45ns on my machine.
>>> With this change, it takes 29ns, which is almost as fast as the pure TSC
>>> implementation.
>>>
>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>> ---
>>>  arch/x86/entry/vdso/vclock_gettime.c | 81 ++++++++++++++++++++----------------
>>>  1 file changed, 46 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c
>>> index ca94fa649251..c325ba1bdddf 100644
>>> --- a/arch/x86/entry/vdso/vclock_gettime.c
>>> +++ b/arch/x86/entry/vdso/vclock_gettime.c
>>> @@ -78,47 +78,58 @@ static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
>>>  
>>>  static notrace cycle_t vread_pvclock(int *mode)
>>>  {
>>> -	const struct pvclock_vsyscall_time_info *pvti;
>>> +	const struct pvclock_vcpu_time_info *pvti = &get_pvti(0)->pvti;
>>>  	cycle_t ret;
>>> -	u64 last;
>>> -	u32 version;
>>> -	u8 flags;
>>> -	unsigned cpu, cpu1;
>>> -
>>> +	u64 tsc, pvti_tsc;
>>> +	u64 last, delta, pvti_system_time;
>>> +	u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
>>>  
>>>  	/*
>>> -	 * Note: hypervisor must guarantee that:
>>> -	 * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
>>> -	 * 2. that per-CPU pvclock time info is updated if the
>>> -	 *    underlying CPU changes.
>>> -	 * 3. that version is increased whenever underlying CPU
>>> -	 *    changes.
>>> +	 * Note: The kernel and hypervisor must guarantee that cpu ID
>>> +	 * number maps 1:1 to per-CPU pvclock time info.
>>> +	 *
>>> +	 * Because the hypervisor is entirely unaware of guest userspace
>>> +	 * preemption, it cannot guarantee that per-CPU pvclock time
>>> +	 * info is updated if the underlying CPU changes or that that
>>> +	 * version is increased whenever underlying CPU changes.
>>>  	 *
>>> +	 * On KVM, we are guaranteed that pvti updates for any vCPU are
>>> +	 * atomic as seen by *all* vCPUs.  This is an even stronger
>>> +	 * guarantee than we get with a normal seqlock.
>>> +	 *
>>> +	 * On Xen, we don't appear to have that guarantee, but Xen still
>>> +	 * supplies a valid seqlock using the version field.
>>> +
>>> +	 * We only do pvclock vdso timing at all if
>>> +	 * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
>>> +	 * mean that all vCPUs have matching pvti and that the TSC is
>>> +	 * synced, so we can just look at vCPU 0's pvti.
>>>  	 */
>>> -	do {
>>> -		cpu = __getcpu() & VGETCPU_CPU_MASK;
>>> -		/* TODO: We can put vcpu id into higher bits of pvti.version.
>>> -		 * This will save a couple of cycles by getting rid of
>>> -		 * __getcpu() calls (Gleb).
>>> -		 */
>>> -
>>> -		pvti = get_pvti(cpu);
>>> -
>>> -		version = __pvclock_read_cycles(&pvti->pvti, &ret, &flags);
>>> -
>>> -		/*
>>> -		 * Test we're still on the cpu as well as the version.
>>> -		 * We could have been migrated just after the first
>>> -		 * vgetcpu but before fetching the version, so we
>>> -		 * wouldn't notice a version change.
>>> -		 */
>>> -		cpu1 = __getcpu() & VGETCPU_CPU_MASK;
>>> -	} while (unlikely(cpu != cpu1 ||
>>> -			  (pvti->pvti.version & 1) ||
>>> -			  pvti->pvti.version != version));
>>> -
>>> -	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
>>> +
>>> +	if (unlikely(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT))) {
>>>  		*mode = VCLOCK_NONE;
>>> +		return 0;
>>> +	}
>>> +
>>> +	do {
>>> +		version = pvti->version;
>>> +
>>> +		/* This is also a read barrier, so we'll read version first. */
>>> +		tsc = rdtsc_ordered();
>>> +
>>> +		pvti_tsc_to_system_mul = pvti->tsc_to_system_mul;
>>> +		pvti_tsc_shift = pvti->tsc_shift;
>>> +		pvti_system_time = pvti->system_time;
>>> +		pvti_tsc = pvti->tsc_timestamp;
>>> +
>>> +		/* Make sure that the version double-check is last. */
>>> +		smp_rmb();
>>> +	} while (unlikely((version & 1) || version != pvti->version));
>>> +
>>> +	delta = tsc - pvti_tsc;
>>> +	ret = pvti_system_time +
>>> +		pvclock_scale_delta(delta, pvti_tsc_to_system_mul,
>>> +				    pvti_tsc_shift);
>>>  
>>>  	/* refer to tsc.c read_tsc() comment for rationale */
>>>  	last = gtod->cycle_last;
>>>
>>
>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Thanks. I've added your Reviewed-by to the 1/5 patch as well - to be able to put 
> the whole series into the tip:x86/entry tree. Let me know if you'd like it to be 
> done differently.

The 1/5 patch is entirely in KVM and is not necessary for the rest of
the series to work.  I would like it to be separate, because Marcelo has
not yet chimed in to say why it was necessary.

Can you just apply patches 2-5?

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289786 — Re: [PATCH 2/5] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On Fri, Dec 11, 2015 at 12:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 11/12/2015 08:52, Ingo Molnar wrote:
>>
>> * Paolo Bonzini <pbonzini@redhat.com> wrote:

>>>
>>> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
>>
>> Thanks. I've added your Reviewed-by to the 1/5 patch as well - to be able to put
>> the whole series into the tip:x86/entry tree. Let me know if you'd like it to be
>> done differently.
>
> The 1/5 patch is entirely in KVM and is not necessary for the rest of
> the series to work.  I would like it to be separate, because Marcelo has
> not yet chimed in to say why it was necessary.
>
> Can you just apply patches 2-5?

Yes, please.  I don't grok the clock update mechanism in the KVM host
well enough to be sure that patch 1 is actually correct.  All I know
is that it works better on my laptop with the patch than without the
patch and that it seems at least conceptually correct.

In any event, patch 1 is a host patch and 2-5 are guest patches, and
they only interact to the extent that it's hard for me to test 2-5 on
the guest without patch 1 on the host because without patch 1 my
laptop's host kernel tends to disable stable kvmclock, thus disabling
the entire mechanism in the guest.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1289094

On Thu, Dec 10, 2015 at 7:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
> NB: patch 1 doesn't really belong here, but it makes this a lot

Ugh, please disregard the resend.  I typoed my git send-email command slightly.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web