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/