[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/3] x86/time: adjust time recording time_calibration_tsc_rendezvous()


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 5 Feb 2021 17:15:20 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oc3FDCN3o1ZwwMC7DuyIq2R1mf6gvpVM0ajBjiuIH9M=; b=EXYVjtvu3lmM09662+RqpjSa5Eoy57VhqLA7EJgOVCbWwlQ/Fpt+PWihcWREDHYRcJmowrGmXqcB8kggx/fvk7/YA1IOckJna+jQxd6epOBX8MB3d5BaWDDmUCfhF7N+LOPqZx/fwZUXICmrnkqNEIdG05ToGGMHshCmZe2UlB2T3y6Uj7Wul0PANBKwi+3dcdb7TloHccM0ZmB5iC3/tebMk5y0yWL7dMgZSoj/FhAPsGe4cDpcJ2/vFdSz8baJPL6Tc7OMbSg2+tXjlrxAhJw7qUfklsjSIoK4NjXVIx5oxP2tcIUdXon+/OeTM1Zb1mXpVRI1a2PLRq3z3dOFIg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kQKvUlpS0i9XPQDalnQpHnkXai7nBxLBqNJ0bLHtfgkxLLtCnViHgsXNFijUT4GH2hwQ1MAk44fEJyImALAFRKzeOnTznTSW3nPOVVU2YhWKUrBJ3P5e/mct5fx67MzXLUqTSGAC+PVwq6CDe4oNEkYOgDmUiA8TCDmpMbbJ7YGQW3xoT3HdDyhdGeKGmsoB1uItacDJ2Rlhx9JFd+A6cQZfS0/rTOIBakxtFM3Ct7LJHS9ujR5zubEJHxabolq2GMn3AyBUN035PKwNCHuPQL8ESLpF+gPGx3BMPLcktVbQ7CHt6E/1jwnBCVTMlW2rGnnbNc0qfO1rFJXIuZrdZw==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Claudemir Todo Bom <claudemir@xxxxxxxxxxx>
  • Delivery-date: Fri, 05 Feb 2021 16:15:35 +0000
  • Ironport-sdr: B/+ETSqGYnLEvGRQFuEZAJZEK+jQyFjBPqMqgKp1BRpRzm3LSYp30bSaJxbS4jNUjjOlmVBcOF SChEckX/5Bgrn4W1mc98OD5J4Y6FlWueDxgaRrUrKS9KZ9QgCBw1hRxzvrYYQwnCENuMiHPxNs t50LIs4Db+Eo33BmfxMiYmurfzP/iUJPITwO9vEJnLfJ8h8r6KW9Z6SYtQVAy+68AJpa4sBaj5 UTDBiYoIJj8MvuuIVMmFzsf9GWE89K+xOYkwB9vZbiT1Qq+PSZOhxHrSCO2A2nlb9bhl3dVwZh tsg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
> Therefore the two better get taken as close to one another as possible.
> This means two things: First, reading platform time is too early when
> done on the first iteration. The closest we can get is on the last
> iteration, immediately before telling other CPUs to write their TSCs
> (and then also writing CPU0's). While at the first glance it may seem
> not overly relevant when exactly platform time is read (when assuming
> that only stime is ever relevant anywhere, and hence the association
> with the precise TSC values is of lower interest), both CPU frequency
> changes and the effects of SMT make it unpredictable (between individual
> rendezvous instances) how long the loop iterations will take. This will
> in turn lead to higher an error than neccesary in how close to linear
> stime movement we can get.
> 
> Second, re-reading the TSC for local recording is increasing the overall
> error as well, when we already know a more precise value - the one just
> written.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

I've been thinking this all seems doomed when Xen runs in a virtualized
environment, and should likely be disabled. There's no point on trying
to sync the TSC over multiple vCPUs as the scheduling delay between
them will likely skew any calculations.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.