Duplication of vdso and vsyscall code?

Duplication of vdso and vsyscall code?

[Jeremy Fitzhardinge]

arch/x86/kernel/vsyscall_64.c implements vgettimeofday and vgetcpu. 
(And vtime)

arch/x86/vdso/vclock_gettime.c implements __vdso_gettimeofday (and
__vdso_clock_gettime), and vgetcpu.c has __vdso_getcpu.

These appear to be functionally identical duplicate definitions.   I
don't understand the history here to know how we came to get two sets of
these functions, but surely we can share the same code for both of these?

Thanks,
    J

Re: Duplication of vdso and vsyscall code?

[Andi Kleen]

On Fri, Oct 09, 2009 at 02:15:58PM -0700, Jeremy Fitzhardinge wrote:
> arch/x86/kernel/vsyscall_64.c implements vgettimeofday and vgetcpu. 
> (And vtime)
> 
> arch/x86/vdso/vclock_gettime.c implements __vdso_gettimeofday (and
> __vdso_clock_gettime), and vgetcpu.c has __vdso_getcpu.
> 
> These appear to be functionally identical duplicate definitions.   I
> don't understand the history here to know how we came to get two sets of
> these functions, but surely we can share the same code for both of these?

One is at a fixed position in the user address space, and the other at a
randomized position. The fixed one came first. Fixed doesn't know
where randomized is. Randomized is also compiled and linked completely
differently. In theory the randomized one could call the fixed one, but
originally there were some thoughts about turning off fixed for some
applications that don't need it and also the path was considered very
performance critical, so unneeded jumps were avoided.
In theory you could probably #include the code from a common file, but it 
wouldn't buy you too much. I think there were originally some 
differences in the vgettimeofday() implementations too, although
that might have changed with all the timer reorganizations.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Duplication of vdso and vsyscall code?

[Jeremy Fitzhardinge]

On 10/09/09 21:14, Andi Kleen wrote:
> One is at a fixed position in the user address space, and the other at a
> randomized position. The fixed one came first. Fixed doesn't know
> where randomized is. Randomized is also compiled and linked completely
> differently.
Is the fixed vsyscall stuff now considered to be legacy?  As far as I
can see, the vdso seems to be what ends up being used on all the systems
I've tried (going back to Fedora 8).

>  In theory the randomized one could call the fixed one, but
> originally there were some thoughts about turning off fixed for some
> applications that don't need it and also the path was considered very
> performance critical, so unneeded jumps were avoided.
>   

rdtsc seems to swamp pretty much everything else.  In my measurements it
alone takes 1/3 of the time.  Though that's Core2; AMD have
traditionally been much better at those kinds of things.

> In theory you could probably #include the code from a common file, but it 
> wouldn't buy you too much.

Yes, that's what I had in mind.  I don't think duplicating the
instructions is all that important, but having two separate similarish
pieces of code seems like a maintenance headache.  I only discovered the
second set of code by accident; I'd assumed that once I'd found one
vgettimeofday I'd found them all (and I'd been assuming that
clock_gettime didn't get the same treatment).

I'll see what happens if I try unifying them...

    J