lkml.org 
[lkml]   [2012]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core
    On Tue, Sep 18, 2012 at 11:02 AM, Richard Cochran
    <richardcochran@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


    \
     
     \ /
      Last update: 2012-09-18 22:41    [W:2.109 / U:1.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site