[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
|
