[lkml]   [2004]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch
    Hash: SHA1

    Jamie Lokier wrote:

    > As this is x86, can't the syscall routines in Glibc call directly
    > without a PLT entry?

    No, since this is just an ordinary jump through the PLT. That the
    target DSO is synthesized is irrelevant. It's which needs the PIC
    setup, not the called DSO.

    > With prelinking, because the vdso is always
    > located at the same address, there isn't even a dirty page overhead to
    > using non-PIC in this case.

    But this isn't true. The address can change. There are already two
    flavors (normal and 4G/4G) and there will probably be more. Ingo would
    have to comment on that.

    > If you have to use a PLT entry it is. If you can do it without a PLT,
    > direct jump to the optimised syscall address is fastest.

    A direct jump is hardcoding the information which is exactly what should
    be avoided.

    > Being Glibc, you could always tweak to only look at the last one
    > if this were really a performance issue. Btw, every syscall used by
    > the program requires at least one symbol lookup, usually over the
    > whole search path, anyway.

    The symbol for the syscall stub in libc is looked up, yes, but nothing
    else. I fail to see the relevence. You cannot say that since a call
    already requires N ns it is OK for it to take 2*N ns.

    > I hear what you're saying. These are the things which bother me:
    > 1. There are already three indirect jumps to make a syscall.
    > (PLT to libc function, indirect jump to vsyscall entry, indirect
    > jump inside kernel). Another is not necessary (in fact two of
    > those aren't necessary either), why add more?

    Because they are all at different level and to abstract out different

    > 2. Table makes the stub for all syscalls slower.

    Not as much as any other acceptable solution. The vdso code is compiled
    for a given address and therefore the memory loads can use absolute

    > All this is moot, though, because in reality only very few syscalls
    > will be optimised, and it doesn't really matter if an older Glibc
    > doesn't take advantage of a newer kernel's optimised version. If
    > someone would like the performance, installing an up to date Glibc is
    > no big deal.

    This is certainly not what many people think. In general, every
    dependency on the runtime for programs to take advantage of new kernel
    features is bad and should be avoided. If I'd write kernel code I'd
    want to control the use as much as possible. And this trivial jump
    table can do this very efficiently.

    > So pragmatically John's solution, with Glibc looking in the vdso just
    > for syscalls it knows have an optimised implementation (i.e. just
    > gettimeofday so far), is best IMHO.

    Pragmatically? How about "practically"? Mind you, for x86 the code
    wouldn't be as simple as the vgettimeofday call on x86-64. For x86-64
    all acceptable kernels had the vsyscall and therefore glibc doesn't have
    to worry about it not being available. And there currently in no second
    or third location for the vDSO.

    For x86 we have to handle in the same binary old kernels and kernels
    where the vDSO is at a different address than the stock kernel. This
    means the computation of the address consists of several step. Get the
    vDSO address (passed up in the auxiliary vector), adding the magic
    offset, and then jumping.

    - --
    ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
    Version: GnuPG v1.2.3 (GNU/Linux)

    -----END PGP SIGNATURE-----
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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