On 10/29/2012 10:42 PM, Marcelo Tosatti wrote:
> 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.
>
I can be wrong, I don't deal with this vdso code for quite a while - so
forgive me if my memory tricked me.
But wasn't it the case that vdso functions could not call functions in
the kernel address space outside the mapped page? Or does this
restriction only apply to accessing data?
--
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
