Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1739124

Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

From Thomas Gleixner <tglx@linutronix.de>
Newsgroups linux.kernel
Subject Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid
Date 2017-09-25 17:40 +0200
Message-ID <utDEe-8eJ-7@gated-at.bofh.it> (permalink)
References <usggF-5zE-3@gated-at.bofh.it> <usggF-5zE-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid <mike.travis@hpe.com> - 2017-09-21 22:30 +0200
  Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being  non-null is valid Thomas Gleixner <tglx@linutronix.de> - 2017-09-25 17:40 +0200
    Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being  non-null is valid Mike Travis <mike.travis@hpe.com> - 2017-09-25 18:50 +0200
      Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being  non-null is valid Thomas Gleixner <tglx@linutronix.de> - 2017-09-25 20:20 +0200
        Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being  non-null is valid Mike Travis <mike.travis@hpe.com> - 2017-09-26 02:20 +0200
          Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being  non-null is valid Thomas Gleixner <tglx@linutronix.de> - 2017-09-26 09:30 +0200

csiph-web