Messages in this thread | | | Date | Fri, 30 Jan 2004 10:29:39 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch |
| |
* Ulrich Drepper <drepper@redhat.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |