x86: Export tsc related information in sysfs
in [Kernel]
|
From: Ingo Molnar on 17 May 2010 20:10 * Dan Magenheimer <dan.magenheimer(a)oracle.com> wrote: > OK, well ignoring the metaphor, it's clear we > disagree on a point that neither one of us can > prove: You think your decision to avoid sharing > kernel information will stop system programmers > from using rdtsc, and I think some are going to use > rdtsc anyway and blame Linux when something > eventually and silently breaks. Applications can do various unreliable things, the kernel cannot do anything about that. The point is for the kernel to not be complicit in practices that are technically not reliable. So the kernel wont 'signal' that something is safe to use if it is not safe to use. One suggestion in this thread makes sense i think: to signal via sysfs that gettimeofday is slow. Plus lets hope that we really can figure out a fast, TSC based gettimeofday implementation. If that is possible then user-space will get a fast gettimeofday right out of box. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 18 May 2010 06:00 On Sun, 2010-05-16 at 22:06 -0700, Arjan van de Ven wrote: > look we're not disabling ring 3 tsc. We could, but we don't. Maybe we should. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 18 May 2010 06:10 On Tue, 2010-05-18 at 11:58 +0200, Peter Zijlstra wrote: > On Sun, 2010-05-16 at 22:06 -0700, Arjan van de Ven wrote: > > look we're not disabling ring 3 tsc. We could, but we don't. > > Maybe we should. We could then trap and emulate it with something sensible like clock monotonic. /me runs :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on 18 May 2010 07:30 On Tue, May 18, 2010 at 11:58:18AM +0200, Peter Zijlstra wrote: > On Sun, 2010-05-16 at 22:06 -0700, Arjan van de Ven wrote: > > look we're not disabling ring 3 tsc. We could, but we don't. > > Maybe we should. That would kill the vsyscall too. Remember it's running in ring 3. That is in theory you could disable it on systems where the vsyscall doesn't use it, but then you would likely break huge amounts of software, unless you emulate it. Emulation would be a possibility, but I'm not sure it would make anyone really happy. It would be certainly slow. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 18 May 2010 08:00
On Tue, 2010-05-18 at 13:25 +0200, Andi Kleen wrote: > On Tue, May 18, 2010 at 11:58:18AM +0200, Peter Zijlstra wrote: > > On Sun, 2010-05-16 at 22:06 -0700, Arjan van de Ven wrote: > > > look we're not disabling ring 3 tsc. We could, but we don't. > > > > Maybe we should. > > That would kill the vsyscall too. Remember it's running in ring 3. > > That is in theory you could disable it on systems where the vsyscall > doesn't use it, but then you would likely break huge amounts of software, > unless you emulate it. Well, software shouldn't use it, so breaking it sounds like a fine idea ;-) Also, a slow emulation is an incentive to actually do the right thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |