From: Stephen Hemminger <stephen@networkplumber.org>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: devel@linuxdriverproject.org,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Haiyang Zhang <haiyangz@microsoft.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
John Stultz <john.stultz@linaro.org>,
Alex Ng <alexng@microsoft.com>, Olaf Hering <olaf@aepfle.de>,
Richard Cochran <richardcochran@gmail.com>
Subject: Re: [PATCH v3 2/2] hv_utils: implement Hyper-V PTP source
Date: Tue, 17 Jan 2017 08:35:47 -0800 [thread overview]
Message-ID: <20170117083547.3c7d71a4@xeon-e3> (raw)
In-Reply-To: <20170117152719.23618-3-vkuznets@redhat.com>
On Tue, 17 Jan 2017 16:27:19 +0100
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> With TimeSync version 4 protocol support we started updating system time
> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
> there is a time sample from the host which triggers do_settimeofday[64]().
> While the time from the host is very accurate such adjustments may cause
> issues:
> - Time is jumping forward and backward, some applications may misbehave.
> - In case an NTP server runs in parallel and uses something else for time
> sync (network, PTP,...) system time will never converge.
> - Systemd starts annoying you by printing "Time has been changed" every 5
> seconds to the system log.
>
> Instead of doing in-kernel time adjustments offload the work to an
> NTP client by exposing TimeSync messages as a PTP device. Users may now
> decide what they want to use as a source.
>
> I tested the solution with chrony, the config was:
>
> refclock PHC /dev/ptp0 poll 3 precision 1e-9
>
> The result I'm seeing is accurate enough, the time delta between the guest
> and the host is almost always within [-10us, +10us], the in-kernel solution
> was giving us comparable results.
>
> I also tried implementing PPS device instead of PTP by using not currently
> used Hyper-V synthetic timers (we use only one of four for clockevent) but
> with PPS source only chrony wasn't able to give me the required accuracy,
> the delta often more that 100us.
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Looks good. Minor style comments.
> ---
> drivers/hv/hv_util.c | 140 ++++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 115 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index 94719eb..e49c5f3 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> +static inline u64 get_timeadj_latency(u64 ref_time)
inline not necessary on static functions. GCC inlines anyway
> +{
> + u64 current_tick;
> +
> + if (ts_srv_version <= TS_VERSION_3)
> + return 0;
> +
> + /*
> + * Some latency has been introduced since Hyper-V generated
> + * its time sample. Take that latency into account before
> + * using TSC reference time sample from Hyper-V.
> + *
> + * This sample is given by TimeSync v4 and above hosts.
> + */
> +
> + rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
Personal preference is not to add blank line between comment
and associated code.
...
> +
> +struct ptp_clock_info ptp_hyperv_info = {
This could be static?
Could it be const?
> + .name = "hyperv",
> + .enable = hv_ptp_enable,
> + .adjtime = hv_ptp_adjtime,
> + .adjfreq = hv_ptp_adjfreq,
> + .gettime64 = hv_ptp_gettime,
> + .settime64 = hv_ptp_settime,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct ptp_clock *hv_ptp_clock;
> +
> static int hv_timesync_init(struct hv_util_service *srv)
> {
> INIT_WORK(&wrk.work, hv_set_host_time);
> +
> + hv_ptp_clock = ptp_clock_register(&ptp_hyperv_info, NULL);
> + if (IS_ERR_OR_NULL(hv_ptp_clock)) {
> + pr_err("cannot register PTP clock: %ld\n",
> + PTR_ERR(hv_ptp_clock));
Why not return error to init routine in case of failure.
> + hv_ptp_clock = NULL;
Why not return error to init routine? Rather than having user
scan log.
> + }
> +
> return 0;
> }
next prev parent reply other threads:[~2017-01-17 16:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 15:27 [PATCH v3 0/2] hv_util: adjust system time smoothly Vitaly Kuznetsov
2017-01-17 15:27 ` [PATCH v3 1/2] hv_util: switch to using timespec64 Vitaly Kuznetsov
2017-01-17 17:37 ` Thomas Gleixner
2017-01-17 15:27 ` [PATCH v3 2/2] hv_utils: implement Hyper-V PTP source Vitaly Kuznetsov
2017-01-17 16:35 ` Stephen Hemminger [this message]
2017-01-17 17:11 ` Vitaly Kuznetsov
2017-01-17 19:17 ` Thomas Gleixner
2017-01-17 16:37 ` [PATCH v3 0/2] hv_util: adjust system time smoothly Stephen Hemminger
2017-01-17 17:15 ` Vitaly Kuznetsov
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=20170117083547.3c7d71a4@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=alexng@microsoft.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=john.stultz@linaro.org \
--cc=kys@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf@aepfle.de \
--cc=richardcochran@gmail.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
/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.