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

Re: [PATCH 2/2] x86/time: improve TSC / CPU freq calibration accuracy


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 17 Jan 2022 09:40:09 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4Lub6VoJCRb/tOK8VZv1GPR4pVEDTwDx13vn1yxivjQ=; b=CbRN5HUMsS2ZIgmS5EFVAJyXKcees7l2Kqp+5rS7tvosnJ+CDRJe1WQEQPADrsk1nPniNXryaqr8O+VhlsO33Mo8b1JXiTVqNgB8DfOizlzZbZWp5EMa6/wMCcEvyyQKH+JVus2ycozAqO1XMeV+41I11OJvYUHQk0v6HoNqSY1/vbEWWP3jQhatl9a5PEVxoPvCjAo7x313Uk90mlqPnl7ru7tyVrj3VLCg5Yp+b38K+XGRJ2LamyEFWGXwLVDD50ZG3oLvWIeW4w/Pplp7q7dNJdS1mYDvX5x6LpZpvo/ohE2PR69DLTMv8V5ntqbC0J0VZpmn/BIetAH0AzKnhg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h2etC3MAfhN/R3qgny0O7g4Iic0evGA3TCOLc22tpw0Z4tJirCYlXNjlb/ZOn/AwCG15IqmSDx0tqdnIh2sEQ5kk+uVl/3W138Yzs/KAIfG85THQO5IhJxTNLDRLzHpKrvocEebLA8YCge2V07mtoqQLK7LQBp4dN426BzrPiUbQdTyrEETM6fg89o6C6d+z16PDVBLz2Sa/RpUIE9k0H9osMmva69asO/qnUVDAI4koChZZQIXNBK4Yn2IsYWBE5iyCX9cVc3LXKV/VDRogqcU0Cc+Es7aB6BGUMCoOjyWHS+wrC3SUjAyprUBb/5YUtFnDofu/sH+u8gEtWro0WQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Mon, 17 Jan 2022 08:40:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 12.01.2022 12:32, Jan Beulich wrote:
> On 12.01.2022 11:53, Roger Pau Monné wrote:
>> On Wed, Jan 12, 2022 at 09:56:12AM +0100, Jan Beulich wrote:
>>> I'm afraid I don't see a way to deal with the same issue in init_pit().
>>> In particular the (multiple) specs I have to hand don't make clear
>>> whether the counter would continue counting after having reached zero.
>>> Obviously it wouldn't help to check this on a few systems, as their
>>> behavior could still be implementation specific.
>>
>> We could likely set the counter to the maximum value it can hold
>> and then perform reads in a loop (like it's done for HPET or the PM
>> timers) and stop when start - target is reached. Not a great solution
>> either.
> 
> Not the least because reading back the counter from the PIT requires
> multiple port operations, i.e. is overall quite a bit slower.

What's worse - even is programmed to the maximum value (65536) this
timer rolls over every 55ms; as said elsewhere SMIs have been observed
to take significantly longer. I conclude that PIT simply cannot safely
be used on platforms with such long lasting operations. As a further
consequence I wonder whether we wouldn't better calibrate the APIC
timer against the chosen platform timer rather than hardcoding this to
use the PIT.

Jan




 


Rackspace

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