Messages in this thread | | | Date | Wed, 20 Feb 2013 11:06:32 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples |
| |
On Tue, 19 Feb 2013, John Stultz wrote: > On 02/19/2013 01:50 PM, Thomas Gleixner wrote: > > 2) Doing #1 will allow to observe the described time going backwards > > scenario in kernel as well. > > > > The reason why we did not get complaints about that scenario at all > > (yet) is that the window and the probability to hit it are small > > enough. Nevertheless it's a real issue for virtualized systems. > > > > Now you came up with the great idea, that the timekeeping core is > > able to calculate what the approximate safe value is for the > > clocksource readout to be in a state where wreckage relative to the > > last update of the clocksource is not observable, not matter how > > long the scheduled out delay is and in which direction the NTP > > update is going. > > So the other bit of caution here, is I realize my idea of "valid cycle ranges" > has the potential for deadlock. > > While it should be fine for use with vdso, we have to be careful if we use > this in-kernel, because if we're in the update path, the valid interval check > could trigger the ktime_get() in hrtimer_interrupt() to spin forever. So we > need to be sure we don't use this method anywhere in the code paths that > trigger the update_wall_time() code.
Hmm, right.
> So some additional thinking may be necessary here. Though it may be as simple > as making sure we don't loop on the cpu that does the timekeeping update.
Either that or make sure to use ktime_get_nocheck() in those code pathes.
Thanks,
tglx
| |