On Thu, 24 Jul 2014 20:31:54 +0000 (UTC) Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > ----- Original Message ----- > > From: "Steven Rostedt" <rostedt@xxxxxxxxxxx> > > To: "Mathieu Desnoyers" <mathieu.desnoyers@xxxxxxxxxxxx> > > Cc: "tip-bot for Thomas Gleixner" <tipbot@xxxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, "john stultz" > > <john.stultz@xxxxxxxxxx>, hpa@xxxxxxxxx, mingo@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx > > Sent: Wednesday, July 23, 2014 8:31:02 PM > > Subject: Re: [tip:timers/core] ftrace: Provide trace clocks monotonic > > > > On Thu, 24 Jul 2014 00:20:11 +0000 (UTC) > > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > > > > > > Therefore, calling it with the same name as the specific user-visible clock > > > it can correlate with (CLOCK_MONOTONIC) seems like a sane choice to me. > > > > Then perhaps we should call it "CLOCK_MONOTONIC". "mono" to me appears > > that the clock is home sick in bed because it kissed someone it > > shouldn't have. > > The main difference here is that time returned by CLOCK_MONOTONIC is expected > to never go backwards between two consecutive reads of a single caller thread. > This new clock does not provide this guarantee, even though it can be correlated > with CLOCK_MONOTONIC. > > I see this clock as being fundamentally the same clock source as clock monotonic, > to which we apply a spreading filter than can fuzz the returned value so the lower > bits can go slightly forward or backwards. > > If we call this clock "CLOCK_NMI_SAFE", and document that it can be correlated with > CLOCK_MONOTONIC, we might end up in a bad situation if we ever want to apply this > same trick to export another nmi-safe clock, e.g. REALTIME or MONOTONIC_RAW. > Therefore, it would be good to keep the name of the clock it correlated to in > the name (monotonic). Again, all the clocks are NMI safe, otherwise they could not be trace clocks. Bad name. > > We're been going through a brainstorm here, here is what we have so far. > CLOCK_MONOTONIC_x, where x is: > > - FUZZED, > - SPREAD, > - DISPERSED, > - DIFFUSE, > - UNORDERED, > - WEAK, > - NMI_SAFE, > - MOSTLY, > - ARGUABLY, > - WHEN_MOON_IS_IN_CRESCENT, > > and then it went downhill from there. ;-) > > Thoughts ? Yeah, back to my original name "user" and document that this lock is correlated with CLOCK_MONOTONIC. But then we can have other user clocks correlate with REALTIME and MONOTONIC_RAW. OK, let's call it "user_mono", as this is the only clock that corresponds to a user clock and that user clock is CLOCK_MONOTONIC. This way we can add "user_raw" and "user_rt" for MONOTONIC_RAW and REALTIME respectively if we need to in the future. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|