[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: Mon, 8 Feb 2021 12:05:16 +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=HQSxXtlHwovMKOHuGQ7hP9hhPtSNIV81Egw7e+KD0M4=; b=jnnlYuc8sWzQ4NchX+gOGsO3ToEL0Ib+sFCePwt4MAzvToe2k4gKDRhqU5PUI678qUtRUdceTLVx6qOzYGKHGt37bgugQd4puVsqOEtJAV7OalzKBGQrEA9lFZgCzVjaix5jbvUJJQkJpzVysEJ0c3EqBK+op4HNWcUtp9K6XUVFPuy49BAmZIpwcNGrPYSpZM2TLp4FpRzrTrZcQjHHOpIv8EGs1E/ZnXj9IUCSKXNKHzYVCRwSnjKXNLuZC5ICv/A92onxokoL1L3K5kbE9sEbjNNUhJcjYIe1nH00m5PNiG40YGKMheTGpLtWNJZrRAddPoCx7s1gzsC/dqJ3yA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m0c2Ee6PAPeZolxy6zBoEl3gzn+X91p9HhJkaCVKqPZFDrmL4cPYFeocm/yqbfGkEk4TCPD6jkqWMb3WA+vHRJL947PsvqnbOC2mTHibR/0R9WBfagKU52RcsogAsZuGc2d6TkbSY39Urz7U2z78oCfO/WdvHsI5i3V4nDPjv4prst8fwFEoXnyvJpqn7ZJkny7aQAJg0yc+HLdd9ppdrN3Mq7X+zIyYD8P+YYinDcOqKJlsqb8FaVKoIxzcnnmK31ExC2uEcbGUmr3UiTISNmBJrXkZKSMNaXK7Z2E/OAmIUzefAC9yYky69gAT2vgthmFhtpgtw76g3hqSqedCIg==
  • Authentication-results: esa6.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: Mon, 08 Feb 2021 11:05:57 +0000
  • Ironport-sdr: +nmeD25TcU2eDIDgaesTGb1/7y81d03nUpgr/1MyDGqCPZPg+0iniLeS5mDuc3/8rF1DWNHgYw SuPjM/qWS05bIBng04GYsnAMaPipYZ8QW7zhm+PJhCs8rR7v8X0aApd+Sm9kH5ZPypBe3frlTA klSfzLxHUHLf1s9OxO+eu3cJccSYYllbqHH/R/64v32E37mx6FxtbZuDIglMMMczhqeQnEKBbO ctZj/eya6BRsYkcZHt0Gd7COVqsWMPdpeqC0MErl4MfIqRyoaoTjBx4B9uVQmGr8UZlSfOJRZA kw8=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
> On 05.02.2021 17:15, Roger Pau Monné wrote:
> > 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>
> 
> Thanks.
> 
> > 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.
> 
> We may want to consider to force the equivalent of
> "clocksource=tsc" in that case. Otoh a well behaved hypervisor
> underneath shouldn't lead to us finding a need to clear
> TSC_RELIABLE, at which point this logic wouldn't get engaged
> in the first place.

I got the impression that on a loaded system guests with a non-trivial
amount of vCPUs might be in trouble to be able to schedule them all
close enough for the rendezvous to not report a big skew, and thus
disable TSC_RELIABLE?

Thanks, Roger.



 


Rackspace

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