On Fri, Feb 26, 2016 at 11:30 AM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > On Fri, Feb 26, 2016 at 09:02:16AM -0800, Andy Lutomirski wrote: >> On Thu, Feb 25, 2016 at 4:20 AM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: >> > 2016-02-24 19:50-0800, Owen Hofmann: >> >> On Wed, Feb 24, 2016 at 5:19 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >>> Of course the guest can run its own NTP daemon or similar adjtimex >> >>> 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, sounds >> >> 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 that >> > passes TSC or CLOCK_MONOTONIC timestamps between hosts needs to handle >> > their differences.) >> >> 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. >> >> --Andy > > Why would you want to do that again? > To fix the suspend/resume problem? > No. Any clock that matches one of the host POSIX clocks would solve the suspend/resume problem. This is for distributed algorithms. If I know that no participant is more than 10ms different from me, then I can take a timestamp, wait 10ms, and then I know that no participant will subsequently get a later timestamp. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
