[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200625141240.53a4094b@oasis.local.home>
Date: Thu, 25 Jun 2020 14:12:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Korben Rusek <korben@...gle.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Masami Hiramatsu <mhiramat@...nel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Yordan Karadzhov <y.karadz@...il.com>,
Tzvetomir Stoyanov <tz.stoyanov@...il.com>,
Tom Zanussi <zanussi@...nel.org>,
Jason Behmer <jbehmer@...gle.com>,
Julia Lawall <julia.lawall@...ia.fr>,
Clark Williams <williams@...hat.com>,
bristot <bristot@...hat.com>, Daniel Wagner <wagi@...om.org>,
Darren Hart <dvhart@...are.com>,
Jonathan Corbet <corbet@....net>,
"Suresh E. Warrier" <warrier@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH] ring-buffer: Have nested events still record
running time stamp
On Thu, 25 Jun 2020 09:42:34 -0700
Korben Rusek <korben@...gle.com> wrote:
> Great work! I'm not exactly qualified to review the code, but the
> logic seems correct. I'm curious how unlikely a zero delta is now and
> how you quantify it. Also does it negate the patch that I emailed out
Actually, in all my stress testing (where I also add nested
trace_printk()s to read what is happening), I was never once able to
trigger the zero delta path! I only tested it by adding code to inject
the event to force the given race condition.
Note, zero deltas are still there between absolute time stamps and
start of page, but that's still different than a zero delta from the
previous event.
> last week that adds a `force_abs_timestamp` trace/option in an attempt
> to get around this particular issue?
>
> In reading through, I did notice a couple simple typos in the comments
> that are probably worth pointing out:
Thanks.
-- Steve
>
> > If preempting an event time update, we may need absolute timestamp.
>
> Not a big deal, but it should be "may need *an* absolute timestamp"
>
> > * Preempted beween C and E:
> > * Lost the previous events time stamp. Just set the
> > * delta to zero, and this will be the same time as
> > * the veent this event preempted. And the events that
> > * came after this will still be correct (as they would
> > * have built their delta on the previous event.
>
> Should be "the *event* this event preempted." It also needs a
> parenthesis at the end of the comment to close the parenthetical
> statement.
>
> Thanks, Korben
Powered by blists - more mailing lists