From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
"Claudemir Todo Bom" <claudemir@todobom.com>
Subject: Re: [PATCH v2 3/3] x86/time: don't move TSC backwards in time_calibration_tsc_rendezvous()
Date: Tue, 2 Feb 2021 09:16:29 +0100 [thread overview]
Message-ID: <22d172b7-bee6-79da-f194-e504ada14871@suse.com> (raw)
In-Reply-To: <80d05abb-4d53-3229-8326-21d79e32dfe4@suse.com>
On 01.02.2021 13:43, Jan Beulich wrote:
> As per the comment ahead of it, the original purpose of the function was
> to deal with TSCs halted in deep C states. While this probably explains
> why only forward moves were ever expected, I don't see how this could
> have been reliable in case CPU0 was deep-sleeping for a sufficiently
> long time. My only guess here is a hidden assumption of CPU0 never being
> idle for long enough.
Furthermore that comment looks to be contradicting the actual use of
the function: It gets installed when !RELIABLE_TSC, while the comment
would suggest !NONSTOP_TSC. I suppose the comment is simply misleading,
because RELIABLE_TSC implies NONSTOP_TSC according to all the places
where either of the two feature bits gets played with. Plus in the
!NONSTOP_TSC case we write the TSC explicitly anyway when coming back
out of a (deep; see below) C-state.
As an implication from the above mwait_idle_cpu_init() then looks to
pointlessly clear "reliable" when "nonstop" is clear.
It further looks odd that mwait_idle() (unlike acpi_processor_idle())
calls cstate_restore_tsc() independent of what C-state was active.
> @@ -1719,9 +1737,12 @@ static void time_calibration_tsc_rendezv
> while ( atomic_read(&r->semaphore) > total_cpus )
> cpu_relax();
> }
> +
> + /* Just in case a read above ended up reading zero. */
> + tsc += !tsc;
> }
>
> - time_calibration_rendezvous_tail(r, r->master_tsc_stamp);
> + time_calibration_rendezvous_tail(r, tsc, r->master_tsc_stamp);
This, in particular, wouldn't be valid when !NONSTOP_TSC without
cstate_restore_tsc(). We then wouldn't have a way to know whether
the observed gap is because of the TSC having been halted for a
while (as the comment ahead of the function - imo wrongly, as per
above - suggests), or whether - like in Claudemir's case - the
individual TSCs were offset against one another.
Jan
next prev parent reply other threads:[~2021-02-02 8:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 12:41 [PATCH v2 0/3] x86/time: calibration rendezvous adjustments Jan Beulich
2021-02-01 12:42 ` [PATCH v2 1/3] x86/time: change initiation of the calibration timer Jan Beulich
2021-02-05 16:00 ` Roger Pau Monné
2021-02-01 12:43 ` [PATCH v2 2/3] x86/time: adjust time recording time_calibration_tsc_rendezvous() Jan Beulich
2021-02-05 16:15 ` Roger Pau Monné
2021-02-08 10:56 ` Jan Beulich
2021-02-08 11:05 ` Roger Pau Monné
2021-02-08 11:50 ` Jan Beulich
2021-02-08 16:39 ` Roger Pau Monné
2021-02-01 12:43 ` [PATCH v2 3/3] x86/time: don't move TSC backwards in time_calibration_tsc_rendezvous() Jan Beulich
2021-02-02 8:16 ` Jan Beulich [this message]
2021-02-08 9:38 ` Roger Pau Monné
2021-02-08 11:22 ` Jan Beulich
2021-02-08 13:19 ` Roger Pau Monné
2021-02-08 13:59 ` Jan Beulich
2021-02-08 16:33 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22d172b7-bee6-79da-f194-e504ada14871@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=claudemir@todobom.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.