* [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
@ 2013-05-30 14:25 David Vrabel
0 siblings, 0 replies; 7+ messages in thread
From: David Vrabel @ 2013-05-30 14:25 UTC (permalink / raw)
To: xen-devel; +Cc: linux-kernel, John Stultz, David Vrabel, Konrad Rzeszutek Wilk
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
itself.
These series fixes the above limitations and depends on "x86: increase
precision of x86_platform.get/set_wallclock()" which was previously
posted.
[ 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. ]
Changes since v2:
Don't peek at the timekeeper internals (use __current_kernel_time()
instead). Use the native set_wallclock hook in dom0.
Changes since v1:
Reworked to use the pvclock_gtod notifier to sync the wallclock (this
looked similar to what a KVM host does). update_persistent_clock()
will now only update the CMOS RTC.
David
[1] http://lists.xen.org/archives/html/xen-devel/2013-05/msg01402.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
2013-05-30 23:55 ` John Stultz
2013-05-31 7:52 ` Jan Beulich
2013-05-31 9:56 ` David Vrabel
@ 2013-05-31 9:56 ` David Vrabel
2 siblings, 0 replies; 7+ messages in thread
From: David Vrabel @ 2013-05-31 9:56 UTC (permalink / raw)
To: John Stultz
Cc: xen-devel, Konrad Rzeszutek Wilk, linux-kernel, Thomas Gleixner
On 31/05/13 00:55, John Stultz wrote:
> On 05/30/2013 07:25 AM, David Vrabel wrote:
>>
>> These series fixes the above limitations and depends on "x86: increase
>> precision of x86_platform.get/set_wallclock()" which was previously
>> posted.
>
> 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
I'm happy for this to be queues for 3.11. Although the series does fix
a bug it's one that I don't think affects that many people (I don't
think I seen any bug reports from anyone else).
We're only rarely seeing the problem in our automated test system which
is not a typical setup.
David
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
2013-05-30 23:55 ` John Stultz
2013-05-31 7:52 ` Jan Beulich
@ 2013-05-31 9:56 ` David Vrabel
2013-05-31 9:56 ` David Vrabel
2 siblings, 0 replies; 7+ messages in thread
From: David Vrabel @ 2013-05-31 9:56 UTC (permalink / raw)
To: John Stultz
Cc: Thomas Gleixner, Konrad Rzeszutek Wilk, linux-kernel, xen-devel
On 31/05/13 00:55, John Stultz wrote:
> On 05/30/2013 07:25 AM, David Vrabel wrote:
>>
>> These series fixes the above limitations and depends on "x86: increase
>> precision of x86_platform.get/set_wallclock()" which was previously
>> posted.
>
> 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
I'm happy for this to be queues for 3.11. Although the series does fix
a bug it's one that I don't think affects that many people (I don't
think I seen any bug reports from anyone else).
We're only rarely seeing the problem in our automated test system which
is not a typical setup.
David
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
2013-05-30 23:55 ` John Stultz
@ 2013-05-31 7:52 ` Jan Beulich
2013-05-31 9:56 ` David Vrabel
2013-05-31 9:56 ` David Vrabel
2 siblings, 0 replies; 7+ messages in thread
From: Jan Beulich @ 2013-05-31 7:52 UTC (permalink / raw)
To: David Vrabel, John Stultz
Cc: Thomas Gleixner, Konrad Rzeszutek Wilk, linux-kernel, xen-devel
>>> On 31.05.13 at 01:55, John Stultz <john.stultz@linaro.org> wrote:
> 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.
Actually, during the v2 discussion I think we made clear that this
is not the goal: Sync-ing of the RTC should be just like native
does it. The only special thing Xen wants is that the hypervisor's
software wall clock wants to be kept up to date when NTP or
whatever else updates Dom0's wall clock.
Jan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
2013-05-30 14:25 David Vrabel
@ 2013-05-30 23:55 ` John Stultz
2013-05-31 7:52 ` Jan Beulich
` (2 more replies)
2013-05-30 23:55 ` John Stultz
1 sibling, 3 replies; 7+ messages in thread
From: John Stultz @ 2013-05-30 23:55 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel, Konrad Rzeszutek Wilk, linux-kernel, Thomas Gleixner
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
> itself.
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
> posted.
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!
thanks
-john
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
2013-05-30 14:25 David Vrabel
2013-05-30 23:55 ` John Stultz
@ 2013-05-30 23:55 ` John Stultz
1 sibling, 0 replies; 7+ messages in thread
From: John Stultz @ 2013-05-30 23:55 UTC (permalink / raw)
To: David Vrabel
Cc: Thomas Gleixner, Konrad Rzeszutek Wilk, linux-kernel, xen-devel
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
> itself.
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
> posted.
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!
thanks
-john
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases
@ 2013-05-30 14:25 David Vrabel
2013-05-30 23:55 ` John Stultz
2013-05-30 23:55 ` John Stultz
0 siblings, 2 replies; 7+ messages in thread
From: David Vrabel @ 2013-05-30 14:25 UTC (permalink / raw)
To: xen-devel; +Cc: David Vrabel, Konrad Rzeszutek Wilk, John Stultz, linux-kernel
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
itself.
These series fixes the above limitations and depends on "x86: increase
precision of x86_platform.get/set_wallclock()" which was previously
posted.
[ 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. ]
Changes since v2:
Don't peek at the timekeeper internals (use __current_kernel_time()
instead). Use the native set_wallclock hook in dom0.
Changes since v1:
Reworked to use the pvclock_gtod notifier to sync the wallclock (this
looked similar to what a KVM host does). update_persistent_clock()
will now only update the CMOS RTC.
David
[1] http://lists.xen.org/archives/html/xen-devel/2013-05/msg01402.html
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-31 9:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-30 14:25 [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases David Vrabel
2013-05-30 14:25 David Vrabel
2013-05-30 23:55 ` John Stultz
2013-05-31 7:52 ` Jan Beulich
2013-05-31 9:56 ` David Vrabel
2013-05-31 9:56 ` David Vrabel
2013-05-30 23:55 ` John Stultz
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.