From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: What time is it kvm-clock? Date: Fri, 26 Feb 2016 16:30:58 -0300 Message-ID: <20160226193056.GA13981@amt.cnet> References: <20160224035753.GA6681@amt.cnet> <20160224233500.GA17304@amt.cnet> <20160225122053.GC18319@potion.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= , Owen Hofmann , Peter Hornyack , KVM General , Paolo Bonzini To: Andy Lutomirski Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46113 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933558AbcBZVe2 (ORCPT ); Fri, 26 Feb 2016 16:34:28 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 26, 2016 at 09:02:16AM -0800, Andy Lutomirski wrote: > On Thu, Feb 25, 2016 at 4:20 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2016-02-24 19:50-0800, Owen Hofmann: > >> On Wed, Feb 24, 2016 at 5:19 PM, Andy Lutomirski wrote: > >>> Of course the guest can run its own NTP daemon or similar adjtime= x > >>> caller and cause the guest to stop tracking the host. But if the= host > >>> passed CLOCK_MONOTONIC through, then the guest would, by default, > >>> treat kvm-clock as an exactly 1GHz source and would then expose a > >>> disciplined NTP-tracking CLOCK_MONOTONIC through to its user apps= even > >>> without an NTP client on the guest. > >>> > >>> If integration with the POSIX clock core were provided, the guest > >>> would learn to consume the host's CLOCK_REALTIME as well, as long= as > >>> the host uses the tsc as its clocksource. > >> > >> Your proposal, which I'd describe as a direct passthrough (to the > >> extent possible) of the host gettimeofday vdso to a kvm guest, sou= nds > >> like a much better way to get clock frequency adjustments from the > >> host to the guest. But I don't know if I can think of a reason to = do > >> this besides "hey you don't have to run ntp". Is there a situation= you > >> have in mind that this helps out? > > > > Running NTP only on the host is a good reason. > > (And probably the only reason I'd call good, because any software t= hat > > passes TSC or CLOCK_MONOTONIC timestamps between hosts needs to ha= ndle > > their differences.) >=20 > There are handful of distributed algorithms that benefit from clocks > with a bounded worst-case synchronization error. I think that Google > uses some. If some cloud provider were to provide, say, 10ms max > CLOCK_REALTIME error and pass CLOCK_REALTIME through using kvm-clock, > it could be quite useful. >=20 > --Andy Why would you want to do that again? To fix the suspend/resume problem?