lkml.org 
[lkml]   [2002]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] linux-2.5.43_vsyscall_A0
    On Fri, Oct 18, 2002 at 11:49:59PM -0500, Jeff Dike wrote:
    > ak@muc.de said:
    > > Guess you'll have some problems then with UML on x86-64, which always
    > > uses vgettimeofday. But it's only used for gettimeofday() currently,
    > > perhaps it's not that bad when the UML child runs with the host's
    > > time.
    >
    > It's not horrible, but it's still broken. There are people who depend
    > on UML being able to keep its own time separately from the host.
    >
    > > I guess it would be possible to add some support for UML to map own
    > > code over the vsyscall reserved locations. UML would need to use the
    > > syscalls then. But it'll be likely ugly.
    >
    > Yeah, it would be.
    >
    > My preferred solution would be for libc to ask the kernel where the vsyscall
    > area is. That's reasonably clean and virtualizable. Andrea doesn't like it
    > because it adds a few instructions to the vsyscall address calculation.

    yes, my preferred solution is still a runtime /proc entry that turns off
    vsyscalls completely by root so you could trap gettimeofday/time via the
    usual ptrace. That would be zero cost. Of course this would be needed
    only for the special users needing a revirtualized time. I tend to think
    most people don't need a revirtualized time in uml, the exceptions can
    run slower [not slower than x86 of course except for an additional
    call/ret pair that won't matter compared to the ptrace overhread of
    every syscall]. I mean, I would prefer to optimize for the people who
    needs fast performance, if you can deal with the ptrace overhead at
    every sysenter/sysret most probably you don't need the vsyscalls in the
    first place.

    My argument is that whatever solution to this problem has a penalty of
    some kind, and I prefer to keep the penalty on the side of the most
    unlikely case, and as far as I can tell it's the case of people needing
    uml running with revirtualized real time. certainly I want to make it
    possible, but I don't care to optimize for it, I want it (not the
    others) to pay for the additional feature it needs.

    If the global sysctl is unacceptable, the next fallback would be to have
    a per-task information that defaults to vsyscall to execute the syscall,
    a check in switch_to could replace the fixmap entry with the one of the
    other vsyscall. That would be an additional single unlikely branch in
    switch_to unless I'm overlooking something and I could live with it
    despite it's not an absolute zero cost. That should be still *much*
    better than glibc asking to kernel the address of the vsyscalls using a
    syscall after execve and using pointer to functions later at runtime to
    invoke the vsyscalls, I don't really like that solution.

    So I would go with:

    1) global sysctl to turn off vgettimeofday/vtime
    2) if 1) is unacceptable then per-task turnoff of vsyscalls would be the
    next viable solution

    Comments?

    Andrea
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.024 / U:60.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site