On 7/31/20 12:05 PM, pet...@infradead.org wrote: > On Fri, Jul 31, 2020 at 08:36:12AM -0700, Andi Kleen wrote: >>> yep, we have a customer that needs to compare data from multiple servers >> >> It's also needed to correlate over different guests on the same machine. >> This is an important use case. > > Both these cases you want to sync up CLOCK_MONOTONIC, using walltime is > just utterly misguided.
Every userspace component logs in walltime. You can say that is misguided, but that is the way it is. The missing piece is the ability to correlate kernel events to userspace logs. > > What happens if the servers have (per accident or otherwise) different > DST settings, or someone does a clock_setttime() for giggles. Yes, someone *could* change the time. Someone *could* start ntpd or other time server in the middle of a session. While technically such things can happen, that is not real life in most environments (e.g., Data center servers). ntpd (or other) is started at boot, and it is just the little misc adjustments that happen over time. We could add tracepoints and detect the changes and invalidate the reference time. We could add tracepoints to track the adjustments and update the reference time. In my experience over 9+ years using this tool (out of tree patches) that has never been the problem. > > All you really want is a clock that runs at the same rate but is not > subject to random jumps and user foibles. > All I want is to compare user logs to a kernel event via timestamps.
