This seems somewhat painful all-around, since if I'm reading this right,
you take a switch_to hit to find out whether the user redirected the
vsyscall, and a vsyscall branch hit as well.
A switch_to seems like something to avoid, since it slows down the
system at all times, even when vgettimeofday is not being used very
often. Does the average system call gettimeofday() more than once per
context switch? If not, don't change switch_to...
If you don't mind a somewhat nasty looking tactic, another way you could
implement something like this and give a boost to virtualizing programs
would be to do a special case in the syscall_trace handler for
gettimeofday.
Just do the global flag test in the vgettimeofday code, and when it does
the fallback system call, if the process is being traced, we check to
see if the control process requested some special handling for the
syscall (obviously very easy to do in kernel mode). If so, do a special
fixup which, say, returns execution back to user space in a
user-specified location without notifying the tracing task of the system
call event.
This way, the main system just sees vsyscalls degrade to normal system
calls, which is ok, and programs that want to virtualize like UML get to
bounce execution into some special user-specified vsyscall code of their
own, with the cost being just one system call transition for UML as
well - a big speedup.
This sort of tactic might be interesting in general for a virtualizing
program, since you could bounce many of the system calls in the traced
process into user-specified code pages (especially if security in the
virtualized program isn't too big a concern).
It also would have the advantage of only mangling the trace path in the
kernel, which isn't the most performance-critical one around, without
overly complicating the vsyscalls in the average case.
Of course, it's kind of... ugly.
-J
-
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/