Re: [PATCH RFC 2/2] x86/time: don't move TSC backwards in time_calibration_tsc_rendezvous()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.01.2021 17:20, Jan Beulich wrote:
> @@ -1696,6 +1696,21 @@ static void time_calibration_tsc_rendezv
>                  r->master_stime = read_platform_stime(NULL);
>                  r->master_tsc_stamp = rdtsc_ordered();
>              }
> +            else if ( r->master_tsc_stamp < r->max_tsc_stamp )
> +            {
> +                /*
> +                 * We want to avoid moving the TSC backwards for any CPU.
> +                 * Use the largest value observed anywhere on the first
> +                 * iteration and bump up our previously recorded system
> +                 * accordingly.
> +                 */
> +                uint64_t delta = r->max_tsc_stamp - r->master_tsc_stamp;
> +
> +                r->master_stime += scale_delta(delta,
> +                                               
> &this_cpu(cpu_time).tsc_scale);
> +                r->master_tsc_stamp = r->max_tsc_stamp;
> +            }

I went too far here - adjusting ->master_stime like this is
a mistake. Especially in extreme cases like Claudemir's this
can lead to the read_platform_stime() visible in context
above reading a value behind the previously recorded one,
leading to NOW() moving backwards (temporarily).

Instead of this I think I will want to move the call to
read_platform_stime() to the last iteration, such that the
gap between the point in time when it was taken and the
point in time the TSCs start counting from their new values
gets minimized. In fact I intend that to also do away with
the unnecessary reading back of the TSC in
time_calibration_rendezvous_tail() - we already know the
closest TSC value we can get hold of (without calculations),
which is the one we wrote a few cycles back.

Jan