[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases

On 05/30/2013 07:25 AM, David Vrabel wrote:
The kernel has limited support for updating the persistent clock or
RTC when NTP is synced.  This has the following limitations:

* The persistent clock is not updated on step changes.  This leaves a
   window where it will be incorrect (while NTP resyncs).

* Xen guests use the Xen wallclock as their persistent clock.  dom0
   maintains this clock so it is persistent for domUs and not dom0

So I'm still skeptical of the urgency to the first patch in this series, as I feel its a little overzealous in trying to enforce strict RTC/system-time synchronization. But that said, these patches are now done in a way that doesn't affect the timekeeping core, so I'm ok with stepping out of the way and leaving the decision to merge it up to the Xen maintainers (Modulo a few nits I still have).

These series fixes the above limitations and depends on "x86: increase
precision of x86_platform.get/set_wallclock()" which was previously

This is the only area that will need some coordination cross the Xen tree and tip/timers/core (once that patch and the fix for it I have queued lands in -tip). The options here are:

* I queue these two patches with proper Xen maintainer's acks/review (possibly adding my grumbles to the commit) * Wait until the requried patch lands tip/timers/core, then Xen maintainers merge tip/timers/core into their tree as well * These patches get rewritten so they don't depend on the "increase precision" patch, then we sort out the merge in -next

The first is probably the easiest, but I do want to make sure that Xen maintainers agree that Xen really needs to be special here compared to every other platform and always enforce the RTC is synced with system time.

[ On a related note, with CONFIG_HZ=1000 sync_cmos_clock() is always
   scheduled ~3ms too late which causes it to repeatedly try to
   reschedule in ~997 ms and ends up never calling
   updated_persistent_clock().  With HZ=250, the error is ~1ms too late
   which is close enough.

   It is not clear where this systematic error comes from or whether
   this is only a Xen specific bug.  I don't have time to investigate
   right now. ]

I'd be very interested in hearing more about this issue!


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.