Messages in this thread | | | Date | Mon, 25 Sep 2017 17:30:40 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid |
| |
On Thu, 21 Sep 2017, mike.travis@hpe.com wrote: > +/* > + * TSC on socket 0 being non-zero may be correct as set by BIOS > + */ > +static int __read_mostly tsc_socket0_nonzero; > + > /* native_sched_clock() is called before tsc_init(), so > we must start with the TSC soft disabled to prevent > erroneous rdtsc usage on !boot_cpu_has(X86_FEATURE_TSC) processors */ > @@ -244,6 +249,20 @@ int check_tsc_unstable(void) > } > EXPORT_SYMBOL_GPL(check_tsc_unstable); > > +void mark_tsc_socket0_nonzero(char *reason) > +{ > + tsc_socket0_nonzero = 1; > + pr_info("Marking TSC non-zero value valid for socket 0 due to %s\n", > + reason); > +} > +EXPORT_SYMBOL_GPL(mark_tsc_socket0_nonzero); > > +int check_tsc_socket0_nonzero(void) > +{ > + return tsc_socket0_nonzero; > +} > +EXPORT_SYMBOL_GPL(check_tsc_socket0_nonzero);
Is there a real reason to export these functions? I can't see the UV early boot code and tsc_sync being built as modules in the forseeable future, but perhaps you know more than I do :)
Aside of that I really do not like this kind of special case hackery. The real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu at all. In principle we don't anymore now that we handle that TSC deadline timer wreckage cleanly.
But the UV 'boot chassis at different times' brings me to a related question:
How is this setup dealing with ART (Always Running Timer, which is distributed over PCIe for hardware timestamping and hardware assisted event correlation)?
I assume that ART on UV is also per chassis, but that means that the documented relation ship of:
TSC = ART * n/d + offset
where $offset is system wide (the TSC_ADJUST value of the boot cpu), is not applicable.
Is there some other magic in play which makes ART work across chassis?
Thanks,
tglx
| |