All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Dario Faggioli <dario.faggioli@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/time: use correct (local) time stamp in constant-TSC calibration fast path
Date: Thu, 9 Jun 2016 13:11:51 +0100	[thread overview]
Message-ID: <57595D07.90107@oracle.com> (raw)
In-Reply-To: <575976AE02000078000F3695@prv-mh.provo.novell.com>



On 06/09/2016 01:01 PM, Jan Beulich wrote:
> This looks like a copy and paste mistake in commit 1b6a99892d ("x86:
> Simpler time handling when TSC is constant across all power saving
> states"), responsible for occasional many-microsecond cross-CPU skew of
> what NOW() returns.
> 
> Also improve the correlation between local TSC and stime stamps
> obtained at the end of the two calibration handlers: Compute the stime
> one from the TSC one, instead of doing another rdtsc() for that
> compuation.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> As to 4.7 inclusion: This of course looks like a pretty blatant mistake
> that has been there for many years (and hence many releases). There's
> certainly non-zero risk that I'm overlooking something here (despite
> Joao apparently having come to the same conclusion), so I can't really
> make up my mind on whether to request this patch to be put there right
> away, or rather having linger in -unstable for a while.
> 
Initially I thought of this as a fix too, but then wouldn't having
t->stime_local_stamp be c->stime_local_stamp, render no use to the
platform timer reads done on calibration? Unless we would change
update_vcpu_system to use stime_master_stamp instead?
stime_master_stamp field isn't used anywhere other than the dom0 injected
cpu_frequency_change or when at boot seeding the cpu_time struct on
init_percpu_time (and the already mentioned use on local_time_calibration) ?
init_percpu_time also takes a different read of the platform timer per
cpu and could probably be inherited by a read done on the boot processor
and written on remaining CPUs, so that all would start from the same stamp.
IOW - this sounds like time we are turning stime to be totally TSC except
when initially seeding each cpu_time?

> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -998,7 +998,7 @@ static void local_time_calibration(void)
>          /* Atomically read cpu_calibration struct and write cpu_time struct. */
>          local_irq_disable();
>          t->local_tsc_stamp    = c->local_tsc_stamp;
> -        t->stime_local_stamp  = c->stime_master_stamp;
> +        t->stime_local_stamp  = c->stime_local_stamp;
>          t->stime_master_stamp = c->stime_master_stamp;
>          local_irq_enable();
>          update_vcpu_system_time(current);
> @@ -1275,7 +1275,7 @@ static void time_calibration_tsc_rendezv
>      }
>  
>      c->local_tsc_stamp = rdtsc();
> -    c->stime_local_stamp = get_s_time();
> +    c->stime_local_stamp = get_s_time_fixed(c->local_tsc_stamp);
>      c->stime_master_stamp = r->master_stime;
>  
>      raise_softirq(TIME_CALIBRATE_SOFTIRQ);
> @@ -1305,7 +1305,7 @@ static void time_calibration_std_rendezv
>      }
>  
>      c->local_tsc_stamp = rdtsc();
> -    c->stime_local_stamp = get_s_time();
> +    c->stime_local_stamp = get_s_time_fixed(c->local_tsc_stamp);
>      c->stime_master_stamp = r->master_stime;
>  
>      raise_softirq(TIME_CALIBRATE_SOFTIRQ);
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-06-09 12:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 12:01 [PATCH] x86/time: use correct (local) time stamp in constant-TSC calibration fast path Jan Beulich
2016-06-09 12:10 ` Andrew Cooper
2016-06-09 12:11 ` Joao Martins [this message]
2016-06-09 12:57   ` Jan Beulich
2016-06-09 15:00     ` Joao Martins
2016-06-09 15:52       ` Jan Beulich
2016-06-09 18:19         ` Joao Martins
2016-06-10  6:59           ` Jan Beulich
2016-06-10  9:29             ` Jan Beulich
2016-06-10 17:07               ` Joao Martins
2016-06-09 12:12 ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57595D07.90107@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.