the sysctl would replace the vsyscall fixmap fixmap entry for the
current cpu enterely at switch_to time, I certainly don't want to add
not necessary branches in the core vsyscall code. Doing it globally is
zerocost but it would probably need privilegies as said, per-task could
be more dynamic without privilegies and it would be an unlikely branch
added in switch_to, still a very low cost so still acceptable.
> For the locked TSC code we will need something like that anyways,
> so that locked TSC can force a syscall.
If we use a per-cpu TSC we don't need the syscall, the cpuid encoded in
each 64bit variable will be enough (see my past email of yesterday
evening, I realized a way to hanle per-cpu info with vsyscalls). the
main problem is as usual that the TSC isn't a real time source, it
changes frequency all the time, but as usual all the problems in the
gettimeofday implementation have little to with the vsyscalls details,
in particular now that I realized how to handle per-cpu data, they're
generic issues that needs solving even if vsyscalls would redirect to
the syscalls.
The only thing we definitely can't do in the vsyscalls is to read the
PIT because it's an old I/O mapped device, but who could ever live only
with the PIT anyways these computing days? If you've only the PIT
vsyscalls or not the gettimeofday functionality would suck.
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/