Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

From: Ingo Molnar
Date: Fri Jan 30 2004 - 08:06:33 EST



* Ulrich Drepper <drepper@xxxxxxxxxx> wrote:

> If gettimeofday() is the only optimized syscall, just add a simple
>
> cmp $__NR_gettimeofday, %eax
> je __vsyscall_gettimeofday
>
> to the __kernel_vsyscall code. With correct static branch prediction
> you'll not be able to measure the effect. The correct way is IMO to
> completely hide the optimizations since otherwise the increased
> dependencies between kernel and libc only create more friction and
> cost and loss of speed.

agreed 100%. Once the # of vsyscalls grows to above a certain treshold,
a table can be used just like we do in kernel-mode.

but i'm a bit worried about the apparent fact that adding 200 more
symbols (and making the vDSO a real DSO in essence) to abstract the
kernel syscalls is apparently unacceptable performance-wise. If this is
true then the whole dynamic linking architecture is much slower than it
should be, isnt it? Why cannot the same argument be made about the ~1400
symbols libc itself provides? Wouldnt a tighter libc API avoid all the
overhead (in fact 7x overhead) you described wrt. adding 200+ kernel
symbols? Why is the kernel vDSO so special [assuming, for the sake of
argument, a clean, versioned function API between libc and the kernel
vDSO]?

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