I can see how glibc can do it slower, but not faster. An
unconditional branch is (almost) free on modern CPUs, using only extra
issue logic. I'm quite certain that using sysenter will be profitable
even if it means going through an extra branch.
Jumping to kernel-specific thunking-code is the way glibc will have to
implement this too. However, glibc doesn't know what kernel version
is available unless it does a system call (or we could map a page with
the version-number that it could read, but then we could just as well
map the thunking-code directly).
Glibc would also like to have this code at a constant offset within
the process to avoid having to go through a pointer, so it would have
to generate code on-the-fly (wastes a page per process), or remap
parts of itself (the part would be dependent on the kernel-version) at
some constant offset to accomplish this.
Another option available to glibc is to use a conditional branch, but
that is certainly not going to be faster than the above, at least not
on an out-of-order CPU.
To me it seems like doing this using glibc would require something
like two extra system-calls during start-up. Maybe it's worth it,
maybe not. However, since the kernel is the part of the system that
has to be prepared for new system-level instructions, putting the
support in glibc necessarily means that you have to implement the
sysenter-feature in two different software packages which has
different policies regarding copyright. If we did system calls
through kernel-provided thunks everybody would have been using
sysenter from day 1.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html