x86: Export tsc related information in sysfs
in [Kernel]
|
From: Brian Bloniarz on 26 May 2010 12:10 On 05/26/2010 11:04 AM, john stultz wrote: > Right but having applications add "Linux on x86 where the TSC is being > used" logic is pretty poor solution. Its an issue that should be > addressed from the kernel side. Yeah, sure. > And really, if apps really wanted this info, they can fish it out > of /proc/cpuinfo. Really? I was under the impression that tsc_khz can differ from cpu_mhz (invariant tsc?), and cpu_mhz can differ from what shows up in /proc/cpuinfo cpuMHz due to cpufreq scaling. I was also under the impression that knowing or controlling tsc_khz is what NTP needs to ensure stability (assuming the TSC is otherwise stable, i.e. no halts-in-idle, NMI etc etc weirdness). Dan Magenheimer wrote: > /sys/devices/system/clocksource/clocksource0/current_khz > > is that an acceptable arch-independent patch? (And which do > you prefer?) Thomas Gleixner: > I'd rather see a generic solution which provides the information of > the current (and possibly those of the available) clock source(s). Another possibility: $ cd /sys/devices/system/clocksource/clocksource0/ $ ls -lR available_clocksource current_clocksource current_clocksource_ln -> tsc tsc/ tsc/calibration tsc/calibrated_master -> ../hpet tsc/khz hpet/ hpet/calibration hpet/khz $ cat tsc/calibration slave # there has been a one-time calibration against a reference at boot time, # the source clock is in calibrated_master and and the khz is calculated # from that $ cat hpet/calibration constant # takes its value from constant value from boot loader, configuration # or some CPU/chipset register Would this be workable? I need to look deeper at how the other clocksources work, for example the virtualized ones. I'm also wondering if NICs with their own clocks & IEEE-1588 support are going to become part of the clocksource infrastructure (see e.g. http://patchwork.ozlabs.org/patch/52626/) Thanks everyone for the guidance. -- 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: john stultz on 26 May 2010 12:30 On Wed, 2010-05-26 at 12:02 -0400, Brian Bloniarz wrote: > On 05/26/2010 11:04 AM, john stultz wrote: > > Right but having applications add "Linux on x86 where the TSC is being > > used" logic is pretty poor solution. Its an issue that should be > > addressed from the kernel side. > > Yeah, sure. > > > And really, if apps really wanted this info, they can fish it out > > of /proc/cpuinfo. > Really? I was under the impression that tsc_khz can differ > from cpu_mhz (invariant tsc?), and cpu_mhz can differ from what > shows up in /proc/cpuinfo cpuMHz due to cpufreq scaling. I was > also under the impression that knowing or controlling tsc_khz > is what NTP needs to ensure stability (assuming the TSC is > otherwise stable, i.e. no halts-in-idle, NMI etc etc weirdness). Bah. You're right. I shouldn't be emailing this early :) Even so, I'm still not a fan of the "expose raw details so userland apps can hack around the kernel's inadequacies" approach. > Dan Magenheimer wrote: > > /sys/devices/system/clocksource/clocksource0/current_khz > > > > is that an acceptable arch-independent patch? (And which do > > you prefer?) > > Thomas Gleixner: > > I'd rather see a generic solution which provides the information of > > the current (and possibly those of the available) clock source(s). While I'm not a huge fan of it, Thomas' way would be a bit more palatable. NTP can check the initial freq the clocksource was registered and if its different from the last boot decide if it can recalculate that into a new correction factor, or just throw out the drift file value. Brian: is this something the NTPd folks actually want? Has anyone checked with them before we hand down the solution from high upon on lkml mountain? Personally I think NTPd should be a little more savvy about how far it trusts the drift file when it starts up. Since I believe its fast-startup mode can quickly estimate the drift well within 100ppm, which is about the maximum variance I've seen from the calibration code. thanks -john -- 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 26 May 2010 14:30 On 05/26/2010 09:25 AM, john stultz wrote: > > Brian: is this something the NTPd folks actually want? Has anyone > checked with them before we hand down the solution from high upon on > lkml mountain? > > Personally I think NTPd should be a little more savvy about how far it > trusts the drift file when it starts up. Since I believe its > fast-startup mode can quickly estimate the drift well within 100ppm, > which is about the maximum variance I've seen from the calibration code. > Engaging with them is probably a good idea. In the past, the NTP core folks have been extremely anti-Linux and pro-BSD and therefore unwilling to talk, but that has at least in part been due to what they perceive as unilateral actions on our part. -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: Brian Bloniarz on 26 May 2010 14:50 On 05/26/2010 12:25 PM, john stultz wrote: > Brian: is this something the NTPd folks actually want? Has anyone > checked with them before we hand down the solution from high upon on > lkml mountain? I haven't checked, it's been a while since I dealt with this problem. The NTP maintainers definitely complain about the quick TSC calibration code like it's a bug: (e.g. http://www.mail-archive.com/questions(a)lists.ntp.org/msg02079.html). Anyway I'll reach out before I spend any time investing in a solution that they don't want (and you don't like :). > Personally I think NTPd should be a little more savvy about how far it > trusts the drift file when it starts up. Since I believe its > fast-startup mode can quickly estimate the drift well within 100ppm, > which is about the maximum variance I've seen from the calibration code. The workaround we went with was to remove the drift file on every reboot. But in our experience, even with iburst, converging takes a long time. I don't have hard numbers since it's been a long time since I investigated the problem, but we defined failure as >1ms offset syncing to a server in our LAN, and a cold NTP boot takes 10-20 hours to get there. I was hoping that being able to reuse the drift information across boots would shorten convergence time. I think that in principle it's a nice thing to be able to do. Though as far as I'm aware, neither chrony nor PTPd (IEEE 1588) attempts to do this. -- 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 26 May 2010 15:00
On 05/26/2010 11:44 AM, Brian Bloniarz wrote: > On 05/26/2010 12:25 PM, john stultz wrote: >> Brian: is this something the NTPd folks actually want? Has anyone >> checked with them before we hand down the solution from high upon on >> lkml mountain? > > I haven't checked, it's been a while since I dealt with > this problem. The NTP maintainers definitely complain about the > quick TSC calibration code like it's a bug: > (e.g. http://www.mail-archive.com/questions(a)lists.ntp.org/msg02079.html). > Anyway I'll reach out before I spend any time investing in > a solution that they don't want (and you don't like :). > Yes, Prof. Mills in particular (for those who don't know, he's "Mr. NTP") really gets upset about the way Linux does timekeeping. Unfortunately it's not clear to me that he's willing to work with us as opposed to wanting things to work exactly like BSD, and swive the non-NTP users. -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/ |