From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Joao Martins <joao.m.martins@oracle.com>, xen-devel@lists.xen.org
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH RFC 2/6] x86/time: implement tsc as clocksource
Date: Tue, 29 Dec 2015 15:11:48 +0000 [thread overview]
Message-ID: <5682A2B4.7060305@citrix.com> (raw)
In-Reply-To: <1451321985-13728-3-git-send-email-joao.m.martins@oracle.com>
On 28/12/2015 16:59, Joao Martins wrote:
> Introduce support for using TSC as platform time which is the highest
> resolution time and most performant to get (~20 nsecs). Though there
> are also several problems associated with its usage, and there isn't a
> complete (and architecturally defined) guarantee that all machines
> will provide reliable and monotonic TSC across all CPUs, on different
> sockets and different P/C states. I believe Intel to be the only that
> can guarantee that. For this reason it's set with less priority when
> compared to HPET unless adminstrator changes "clocksource" boot option
> to "tsc". Upon initializing it, we also check for time warps and
> appropriate CPU features i.e. TSC_RELIABLE, CONSTANT_TSC and
> NONSTOP_TSC. And in case none of these conditions are met, we fail in
> order to fallback to the next available clocksource.
>
> It is also worth nothing that with clocksource=tsc there isn't no
I presume you mean "worth noting" and either "is no" or "isn't any"?
However, looking at the sentence below, do you mean "isn't any need to
synchronise with another clocksource" ?
> synchronization with another clocksource, and I could verify that
> great portion the time skew was eliminated and seeing much less time
> warps happening. With HPET I used to observe ~500 warps in the period
> of 1h of around 27 us, and with TSC down to 50 warps in the same
> period having each warp < 100 ns. The warps still exist though but
> are only related to cross CPU calibration (being how much it takes to
> rendezvous with master), in which a later patch in this series aims to
> solve.
>
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
> xen/arch/x86/time.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
> index 30d52c4..c9e5c14 100644
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -433,6 +433,64 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
> }
>
> /************************************************************
> + * PLATFORM TIMER 4: TSC
> + */
> +static bool_t clocksource_is_tsc = 0;
What does clocksource_is_tsc signify? It looks to be unused in this patch.
~Andrew
next prev parent reply other threads:[~2015-12-29 15:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-28 16:59 [PATCH RFC 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support Joao Martins
2015-12-28 16:59 ` [PATCH RFC 1/6] public/xen.h: add flags field to vcpu_time_info Joao Martins
2016-01-25 20:11 ` Konrad Rzeszutek Wilk
2016-01-26 10:31 ` Joao Martins
2015-12-28 16:59 ` [PATCH RFC 2/6] x86/time: implement tsc as clocksource Joao Martins
2015-12-29 15:11 ` Andrew Cooper [this message]
2015-12-29 17:37 ` Joao Martins
2015-12-28 16:59 ` [PATCH RFC 3/6] x86/time: streamline platform time init on plt_init() Joao Martins
2016-01-25 20:26 ` Konrad Rzeszutek Wilk
2016-01-26 10:31 ` Joao Martins
2015-12-28 16:59 ` [PATCH RFC 4/6] x86/time: refactor read_platform_stime() Joao Martins
2015-12-28 16:59 ` [PATCH RFC 5/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT Joao Martins
2015-12-28 16:59 ` [PATCH RFC 6/6] x86/time: convert counter to tsc for non-tsc clocksource Joao Martins
2015-12-29 14:58 ` [PATCH RFC 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support Andrew Cooper
2015-12-29 17:37 ` Joao Martins
2016-02-22 21:14 ` Joao Martins
2016-02-23 8:09 ` Jan Beulich
2016-02-23 12:13 ` Joao Martins
2015-12-30 3:47 ` Haozhong Zhang
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=5682A2B4.7060305@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=joao.m.martins@oracle.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.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.