On 05/02/2017 04:47 PM, Sage Weil wrote:
On Tue, 2 May 2017, Mohamad Gebai wrote:
Image [2] shows a better image of the call stack view, and Image [3] shows a
better one of the critical path.
The code is in branch [4].
These are awesome! What is the tool you're screenshotting to visualize?
Sorry, I forgot to mention that part. The viewing tool is TraceCompass
(use with an SSD because the traces are quite big).
It would be great to apply the build options based on an option passed to
cmake (e.g, -DWITH_INSTRUMENT_FUNCTIONS).
That's definitely an option, I'll submit a patch. The thing is that it
also needs -no-pie in order to resolve the function addresses at
analysis time.
Also, I wonder if these are a better/simpler alternative to the
FUNCTRACE() macro in src/common/EventTrace.h. What kind of overhead is
introduced? LTTNG lets you enable on specific tracepoints, right?
Indeed, but these are all the same tracepoint (function_entry and
function_exit, with different payloads depending on the function that is
called). We could also limit the stack depth to stop tracing after a
certain number of nested function calls.
I've done some benchmarking of LTTng in the past. On average, a kernel
tracepoint costs less than 100ns and a userspace one is around 150ns. It
also hits the disk to periodically flush the tracing buffers. The
overhead is definitely non negligeable. I'll write a how-to as there are
quite a few steps to get all of this running.
Mohamad
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
