On Tue, 24 Aug 2010 22:08:09 +0200 Björn JACKE <bj@xxxxxxxxx> wrote: > On 2010-08-24 at 14:34 -0400 Jeff Layton sent off: > > > > Any pointers to background on gettimeofday vs > > > > clock_gettime(CLOCK_MONOTONIC) and why the latter is better? > > > > > > IIUC, the reason for this is that gettimeofday is affected by wallclock > > > changes (think NTP): > > > > > > CLOCK_MONOTONIC > > > Clock that cannot be set and represents monotonic time since > > > some unspecified starting point. > > > > > > ...so by preferring CLOCK_MONOTONIC, the mtab locking code isn't > > > affected by clock jumps or skew. Bjorn, is this correct? > > yes, correct. In the worst case you start a timeout period while the clock is > set to 2020, during the timeout period the clock is corrected by ntpdate. In > that case the timeout using the RTC clock is a bit longer than expected :-) > > > > Correction...CLOCK_MONOTONIC is affected by adjtimex(). Over a 30s > > period though, that shouldn't mean much of a delta. The big danger is > > large clock jumps and this should take care of that. > > > > Out of curiousity though...did you or someone you know hit this problem > > in practice, Bjorn? Or did you just notice it via inspection? > > you see all kinds of strange timing effects if you have a VM that has > an unstable clock which you need to regulary adjust had via ntpdate for > example. Programs hang or for a hile or forever in the worst case. I didn't > see a problem in this particular case with mount.cifs but as this is something > which is called at boot time where ntpdate often runs at the sme time to > initally hard reset the clock this is something I thought should to be > adjusted to use the monotonic clock. > Ok, thanks for the clarification. Committed... This should make the 4.7 release. Thanks! -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
