From: Mark Nelson <mnelson@redhat.com>
To: Mohamad Gebai <mgebai@suse.com>, Sage Weil <sage@newdream.net>
Cc: anjaneya.chagam@intel.com, ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: Tracing Ceph results
Date: Tue, 2 May 2017 19:49:38 -0500 [thread overview]
Message-ID: <871b2d01-6da2-0e8b-c034-d375e719aeed@redhat.com> (raw)
In-Reply-To: <51909d0c-e1de-d349-1515-80a85427aebf@suse.com>
On 05/02/2017 04:05 PM, Mohamad Gebai wrote:
> 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.
Awesome job Mohamad! It'd be sweet if we could automate the tracing and
geneation of plots like this. Some time I'd like to be able to include
tracing like this during CBT benchmark runs.
Mark
>
> Mohamad
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-03 0:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 20:21 Tracing Ceph results Mohamad Gebai
2017-05-02 20:47 ` Sage Weil
2017-05-02 21:05 ` Mohamad Gebai
2017-05-03 0:49 ` Mark Nelson [this message]
2017-05-03 13:45 ` Mohamad Gebai
2017-05-03 13:43 ` Jason Dillaman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871b2d01-6da2-0e8b-c034-d375e719aeed@redhat.com \
--to=mnelson@redhat.com \
--cc=anjaneya.chagam@intel.com \
--cc=ceph-devel@vger.kernel.org \
--cc=mgebai@suse.com \
--cc=sage@newdream.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.