Re: [PATCH] x86: Export tsc related information in sysfs

[Brian Bloniarz <bmb@athenacr.com>]

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.