[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLXQbXgYbA4gS9ju7iEQRu_s4eMCEneiaJY0JGpQh+Qu2A@mail.gmail.com>
Date: Fri, 6 Jan 2017 16:56:23 -0800
From: John Stultz <john.stultz@...aro.org>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
lkml <linux-kernel@...r.kernel.org>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Thomas Gleixner <tglx@...utronix.de>,
Alex Ng <alexng@...rosoft.com>,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: [PATCH v2 3/4] hv_util: use do_adjtimex() to update system time
On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov <vkuznets@...hat.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 client is run in parallel things may go south, e.g. when
> an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY
> the Hyper-V module will not see this changes and time will oscillate and
> never converge.
> - Systemd starts annoying you by printing "Time has been changed" every 5
> seconds to the system log.
>
> Instead of calling do_settimeofday64() we can pretend being an NTP client
> and use do_adjtimex(). Do do_settimeofday64() in case the difference is too
> big or ICTIMESYNCFLAG_SYNC flag was set in the request.
So how does having the guest kernel (on behalf of the host) calling
adjtimex internally interact with NTP clients running on the guest?
The kernel sort of assumes a single user of adjtimex (having multiple
clients adjusting the clock doesn't work out so well).
thanks
-john
Powered by blists - more mailing lists