[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/4] x86/time: further improve TSC / CPU freq calibration accuracy
- To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Fri, 11 Mar 2022 13:30:53 +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=7ehG6zKVsTFwvNcCOOtzFk9BpNnW17evCWMJKGkeAmw=; b=MjfkiS4aA17J+1TDGBdShM9UvIdPrn/PVAYPgqvWnVSJBIWMhfT8xUL/K96KUrdqhnyqyM366zjoYqJCqk0qPTsycr6ROOEyOUYklYWVXe6EEVrv6D0LD1pGFwXG5uvGtELE3WVTt6GeBGHR/sIi2snn7e6s/7qeFED56SV9cM1DcNWIKfCSsVmVtd1uQgIn3x7wd9Q7qtzN+00rhMzhledUdYVWEDWkKsppvvDeQBpO1r3Kc+z4tNhZBVV0rmGhZalOOlE799P0tJUbWnc825C2ksmXhec1js+mZsyqOuknT1dNfR7iJW1oLSMyyYSUkEIq1V7PdEQJM7rrG/0Grg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oZNPw964XH14zYF6wt1NxpxsVoplEsAoNm+XsO9vc6iDkw4a1PifV/gPEDLaEHh6byBVyEPkoX/8gnE3X4fwEsgO5gmGROYrMjQgW/dxrPsQ6jtDptEzJFkxQ0JwH1JsTmhmdhReml3eEOXDv/uUW9D7hCrRIuzVSxqDaToT55ke85ttSpiKB/bOj0rJw8txqTBpabfwVsSqbceYTDakJ6qp4zvL6gjzXYnXi7NfNRvM61+LRiRisnls9Wz3dq+fsnuw06239mI5BZCxvPmK43ARxDdGrl20Tr8XXC/RAwNQqvcgdkQPZErdqKRiBf9wC+P6cmaRy8BS/juWCfSu1w==
- 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: Fri, 11 Mar 2022 12:31:09 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11.03.2022 13:03, Roger Pau Monné wrote:
> On Mon, Feb 14, 2022 at 10:24:49AM +0100, Jan Beulich wrote:
>> Calibration logic assumes that the platform timer (HPET or ACPI PM
>> timer) and the TSC are read at about the same time. This assumption may
>> not hold when a long latency event (e.g. SMI or NMI) occurs between the
>> two reads. Reduce the risk of reading uncorrelated values by doing at
>> least four pairs of reads, using the tuple where the delta between the
>> enclosing TSC reads was smallest. From the fourth iteration onwards bail
>> if the new TSC delta isn't better (smaller) than the best earlier one.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Thanks.
>> ---
>> When running virtualized, scheduling in the host would also constitute
>> long latency events. I wonder whether, to compensate for that, we'd want
>> more than 3 "base" iterations, as I would expect scheduling events to
>> occur more frequently than e.g. SMI (and with a higher probability of
>> multiple ones occurring in close succession).
>
> That's hard to tell, maybe we should make the base iteration count
> settable from the command line?
As a last resort (if people observe problems) - maybe. It's not clear to me
though on what basis an admin would choose another value.
Jan
|
