From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more) Date: Tue, 2 Aug 2016 20:30:15 +0100 Message-ID: <8efd4ae7-723e-ecf1-5a8c-6ace41cc12d3@citrix.com> References: <576140F302000078000F52FE@prv-mh.provo.novell.com> <5761496802000078000F5395@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2828655433951443244==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUfOT-0006JI-Ex for xen-devel@lists.xenproject.org; Tue, 02 Aug 2016 19:30:25 +0000 In-Reply-To: <5761496802000078000F5395@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich , xen-devel Cc: Dario Faggioli , Joao Martins List-Id: xen-devel@lists.xenproject.org --===============2828655433951443244== Content-Type: multipart/alternative; boundary="------------6F53F7AB891308E3BFB7DFFC" --------------6F53F7AB891308E3BFB7DFFC Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit On 15/06/16 11:26, Jan Beulich wrote: > Using the bare return value from read_platform_stime() is not suitable > when local_time_calibration() is going to use its fast path: Divergence > of several dozen microseconds between NOW() return values on different > CPUs results when platform and local time don't stay in close sync. > > Latch local and platform time on the CPU initiating AP bringup, such > that the AP can use these values to seed its stime_local_stamp with as > little of an error as possible. The boot CPU, otoh, can simply > calculate the correct initial value (other CPUs could do so too with > even greater accuracy than the approach being introduced, but that can > work only if all CPUs' TSCs start ticking at the same time, which > generally can't be assumed to be the case on multi-socket systems). > > This slightly defers init_percpu_time() (moved ahead by commit > dd2658f966 ["x86/time: initialise time earlier during > start_secondary()"]) in order to reduce as much as possible the gap > between populating the stamps and consuming them. > > Signed-off-by: Jan Beulich Subject to the style issue spotted by Joao, Reviewed-by: Andrew Cooper --------------6F53F7AB891308E3BFB7DFFC Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit
On 15/06/16 11:26, Jan Beulich wrote:
Using the bare return value from read_platform_stime() is not suitable
when local_time_calibration() is going to use its fast path: Divergence
of several dozen microseconds between NOW() return values on different
CPUs results when platform and local time don't stay in close sync.

Latch local and platform time on the CPU initiating AP bringup, such
that the AP can use these values to seed its stime_local_stamp with as
little of an error as possible. The boot CPU, otoh, can simply
calculate the correct initial value (other CPUs could do so too with
even greater accuracy than the approach being introduced, but that can
work only if all CPUs' TSCs start ticking at the same time, which
generally can't be assumed to be the case on multi-socket systems).

This slightly defers init_percpu_time() (moved ahead by commit
dd2658f966 ["x86/time: initialise time earlier during
start_secondary()"]) in order to reduce as much as possible the gap
between populating the stamps and consuming them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

Subject to the style issue spotted by Joao, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--------------6F53F7AB891308E3BFB7DFFC-- --===============2828655433951443244== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============2828655433951443244==--