On Tue, Sep 18, 2012 at 11:02 AM, Richard Cochran <richardcoch...@gmail.com> wrote: > On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote: >> On 09/17/2012 04:49 PM, Andy Lutomirski wrote: >> >2. There's nothing vsyscall-specific about the code in >> >vclock_gettime.c. In fact, the VVAR macro should work just fine in >> >kernel code. If you moved all this code into a header, then in-kernel >> >uses could use it, and maybe even other arches could use it. Last >> >time I checked, it seemed like vclock_gettime was considerably faster >> >than whatever the in-kernel equivalent did. >> I like the idea of unifying the implementations, but I'd want to >> know more about why vclock_gettime was faster then the in-kernel >> getnstimeofday(), since it might be due to the more limited locking >> (we only update vsyscall data under the vsyscall lock, where as the >> timekeeper lock is held for the entire execution of >> update_wall_time()), or some of the optimizations in the vsyscall >> code is focused on providing timespecs to userland, where as >> in-kernel we also have to provide ktime_ts. > > This there a valid technical reason why each arch has its own vdso > implementation?
I don't know too much about other arch vdsos. i386's doesn't have clock functions. x32 works exactly like x86-64, except that it probably involves a bit of addressing mode weirdness. ia64's is very strange indeed, I think. In any case, the VVAR macro is an x86-64-ism, although if it were to be the beginning of a generic mechanism, #define VVAR(x) (x) would be a perfectly fine start, I think. > > If not, I would suggest that the first step would be to refactor these > into one C-language header. If this can be shared with kernel code, > then all the better. That should be most straightforward to do. One issue: you can't call a function pointer from vdso code (because the vdso is in a different place in different processes). The vclock_mode stuff would need to be extended to work across architectures, and the fallback to a real syscall would need to turn into something else. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
