x86: Export tsc related information in sysfs
in [Kernel]
|
From: H. Peter Anvin on 18 May 2010 15:00 On 05/18/2010 10:49 AM, Dan Magenheimer wrote: > > (Though I expect tglx/arjan/andi/mingo to disagree with this proposal > for similar reasons as the original one that started this thread...) > I'll add another reason to disagree: exporting these as sysfs variables is non-atomic, but these are really only useful when atomically read as a unit. -hpa -- 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: Dan Magenheimer on 18 May 2010 15:20 > From: Dan Magenheimer > > > From: H. Peter Anvin [mailto:hpa(a)zytor.com] > > Subject: Re: [PATCH] x86: Export tsc related information in sysfs > > > > On 05/18/2010 10:49 AM, Dan Magenheimer wrote: > > > > > > (Though I expect tglx/arjan/andi/mingo to disagree with this > proposal > > > for similar reasons as the original one that started this > thread...) > > > > I'll add another reason to disagree: exporting these as sysfs > variables > > is non-atomic, but these are really only useful when atomically read > as > > a unit. > > Which "these"? The counters? I would think the primary use > of the counters is to diagnose extreme problem cases, not > to differentiate whether a system or process did exactly > 27 vs 28 rdtsc's, so I don't see why atomic read is at all > necessary. > > Or did I miss your point entirely? Oops, hit send too soon. And the reason I expect tglx/arjan/andi/mingo to disagree is because their position is that there is NO safe use for rdtsc in userspace EVER! Whereas your position stated earlier: > There are restricted uses of the TSC in userspace which are still > useful > (mainly involving performance analysis and/or CPU-locked processes). says there are. While the engineer in me agrees with tglx/arjan/andi/mingo, the realist in me agrees with you. -- 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: H. Peter Anvin on 18 May 2010 15:40 On 05/18/2010 12:16 PM, Dan Magenheimer wrote: > > Oops, hit send too soon. > > And the reason I expect tglx/arjan/andi/mingo to disagree is because > their position is that there is NO safe use for rdtsc in userspace EVER! > Whereas your position stated earlier: > >> There are restricted uses of the TSC in userspace which are still >> useful >> (mainly involving performance analysis and/or CPU-locked processes). > > says there are. > > While the engineer in me agrees with tglx/arjan/andi/mingo, the > realist in me agrees with you. I should have added "that are not related to wall time" to the statement above. Furthermore, vsyscalls are user space from a CPU perspective. -hpa -- 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: Dan Magenheimer on 18 May 2010 15:40 > From: H. Peter Anvin [mailto:hpa(a)zytor.com] > Subject: Re: [PATCH] x86: Export tsc related information in sysfs > > On 05/18/2010 10:49 AM, Dan Magenheimer wrote: > > > > (Though I expect tglx/arjan/andi/mingo to disagree with this proposal > > for similar reasons as the original one that started this thread...) > > I'll add another reason to disagree: exporting these as sysfs variables > is non-atomic, but these are really only useful when atomically read as > a unit. Which "these"? The counters? I would think the primary use of the counters is to diagnose extreme problem cases, not to differentiate whether a system or process did exactly 27 vs 28 rdtsc's, so I don't see why atomic read is at all necessary. Or did I miss your point entirely? -- 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: Dan Magenheimer on 18 May 2010 16:40
> From: H. Peter Anvin [mailto:hpa(a)zytor.com] > Subject: Re: [PATCH] x86: Export tsc related information in sysfs > > On 05/18/2010 12:16 PM, Dan Magenheimer wrote: > > And the reason I expect tglx/arjan/andi/mingo to disagree is because > > their position is that there is NO safe use for rdtsc in userspace > EVER! > > Whereas your position stated earlier: > > > >> There are restricted uses of the TSC in userspace which are still > >> useful > >> (mainly involving performance analysis and/or CPU-locked processes). > > > > says there are. > > > > While the engineer in me agrees with tglx/arjan/andi/mingo, the > > realist in me agrees with you. > > I should have added "that are not related to wall time" to the > statement above. Yes... that still puts your opinion at odds with tglx/etc. All of the cases I am concerned with ARE performance analysis uses, not wall time uses. > Furthermore, vsyscalls are user space from a CPU perspective. Yes, understood, a minor semantic issue. From a kernel perspective vsyscalls are kernelspace, so IIUC this is OK with tglx/etc. Since vsyscall shouldn't be using rdtsc when the kernel doesn't trust TSC, it doesn't matter if CR4.TSD is enabled when the kernel doesn't trust TSC. I'm still not sure if you are in favor of optionally emulating PL3 rdtsc instructions or not? I thought my proposal was just filling out some details of your proposal and suggesting a default. -- 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/ |