[PATCH 0/3] ring-buffer: Restructure ftrace ring buffer time keeping to allow accurate nested timing
From: Steven Rostedt
Date: Fri Jun 26 2020 - 21:25:36 EST
I completed some thorough testing on these patches now, and have injected
trace_printk()s (in a way to allow it to safely recurse) to force various
data races and then examined the trace to make sure that everything it did
was exactly what I expect it to do, or in cases where it did something
surprising, I found that it was still a legitimate case! ;-)
I found a few bugs along the way, but it all still very much matches the
original design. The bugs were more in the implementation. But now that I
feel I have those all straighten out, I'm much more confident in this code
(famous last words!).
Although I did do a lot of custom testing (with all the injecting of
trace_printk()s), I have only run these through my standard smoke tests and
have not yet run these through my main test suite (13 hour run time). But
will do that when I have other non related patches ready to go with it.
But for now, these are very close to my finished product. Feel free to try
to poke holes in this as well.
Special thanks to Mathieu Desnoyers for his annoying critique (and I mean
that in a very positive way!). If it wasn't for his comments, I would have
missed fixing a small design flaw (the switch back to delta time instead of
keeping with the full time stamp). It turned out that that path had other
issues, and without removing that path, I would not have been able to add
the last patch of this series.
Cheers.
-- Steve
Steven Rostedt (VMware) (3):
ring-buffer: Have nested events still record running time stamp
ring-buffer: Incorporate absolute timestamp into add_timestamp logic
ring-buffer: Add rb_time_t 64 bit operations for speeding up 32 bit
----
kernel/trace/ring_buffer.c | 503 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 406 insertions(+), 97 deletions(-)