Re: [patch 12/18] x86: vdso: pvclock gettime support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 29, 2012 at 06:59:35PM +0400, Glauber Costa wrote:
> On 10/24/2012 05:13 PM, Marcelo Tosatti wrote:
> > Improve performance of time system calls when using Linux pvclock, 
> > by reading time info from fixmap visible copy of pvclock data.
> > 
> > Originally from Jeremy Fitzhardinge.
> > 
> > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
> > 
> > Index: vsyscall/arch/x86/vdso/vclock_gettime.c
> > ===================================================================
> > --- vsyscall.orig/arch/x86/vdso/vclock_gettime.c
> > +++ vsyscall/arch/x86/vdso/vclock_gettime.c
> > @@ -22,6 +22,7 @@
> >  #include <asm/hpet.h>
> >  #include <asm/unistd.h>
> >  #include <asm/io.h>
> > +#include <asm/pvclock.h>
> >  
> >  #define gtod (&VVAR(vsyscall_gtod_data))
> >  
> > @@ -62,6 +63,69 @@ static notrace cycle_t vread_hpet(void)
> >  	return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 0xf0);
> >  }
> >  
> > +#ifdef CONFIG_PARAVIRT_CLOCK_VSYSCALL
> > +
> > +static notrace const struct pvclock_vsyscall_time_info *get_pvti(int cpu)
> > +{
> > +	const aligned_pvti_t *pvti_base;
> > +	int idx = cpu / (PAGE_SIZE/PVTI_SIZE);
> > +	int offset = cpu % (PAGE_SIZE/PVTI_SIZE);
> > +
> > +	BUG_ON(PVCLOCK_FIXMAP_BEGIN + idx > PVCLOCK_FIXMAP_END);
> > +
> > +	pvti_base = (aligned_pvti_t *)__fix_to_virt(PVCLOCK_FIXMAP_BEGIN+idx);
> > +
> > +	return &pvti_base[offset].info;
> > +}
> > +
> 
> Unless I am missing something, if gcc decides to not inline get_pvti,
> this will break, right? I believe you need to mark that function with
> __always_inline.

Can't see why. Please enlighten me.

> 
> > +static notrace cycle_t vread_pvclock(int *mode)
> > +{
> > +	const struct pvclock_vsyscall_time_info *pvti;
> > +	cycle_t ret;
> > +	u64 last;
> > +	u32 version;
> > +	u32 migrate_count;
> > +	u8 flags;
> > +	unsigned cpu, cpu1;
> > +
> > +
> > +	/*
> > +	 * When looping to get a consistent (time-info, tsc) pair, we
> > +	 * also need to deal with the possibility we can switch vcpus,
> > +	 * so make sure we always re-fetch time-info for the current vcpu.
> > +	 */
> > +	do {
> > +		cpu = __getcpu() & 0xfff;
> 
> Please wrap this 0xfff into something meaningful.

OK.

> > +		pvti = get_pvti(cpu);
> > +
> > +		migrate_count = pvti->migrate_count;
> > +
> > +		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() & 0xfff;
> > +	} while (unlikely(cpu != cpu1 ||
> > +			  (pvti->pvti.version & 1) ||
> > +			  pvti->pvti.version != version ||
> > +			  pvti->migrate_count != migrate_count));
> > +
> > +	if (unlikely(!(flags & PVCLOCK_TSC_STABLE_BIT)))
> > +		*mode = VCLOCK_NONE;
> > +
> > +	last = VVAR(vsyscall_gtod_data).clock.cycle_last;
> > +
> > +	if (likely(ret >= last))
> > +		return ret;
> > +
> 
> Please add a comment here referring to tsc.c, where an explanation of
> this test lives. This is quite non-obvious for the non initiated.

OK.

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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux