From: fche@redhat.com (Frank Ch. Eigler)
To: Aubrey Li <aubreylee@gmail.com>
Cc: systemtap@sourceware.org
Subject: Re: kernel function probe overhead
Date: Fri, 25 Nov 2016 17:22:00 -0000 [thread overview]
Message-ID: <y0m1sxzpj9i.fsf@fche.csb> (raw)
In-Reply-To: <CAGPKeUKWAvBv=SL_ebVkR3ZwCeGZoCQ1MEJ5xQi-VXuF=kt3Wg@mail.gmail.com> (Aubrey Li's message of "Sat, 26 Nov 2016 00:07:51 +0800")
aubreylee wrote:
> [...]
> Basically I sampled two kernel function probes,
>
> probe kernel.function(arch_cpu_idle_enter).call
> probe kernel.function(local_touch_nmi).call
... where one directly calls the other. Good test!
> because local irq is disabled, I suppose the duration of these two
> probes to be ZERO.
Yes, ideally.
> However, I run the attached stp script and here is what I got:
> [...]
> Total time: 10106 miliseconds
> t_end @count=2908 @min=676 @max=88152 @sum=15005802 @avg=5160
> the duration varies from 676 to 88152, I understand all the tracing
> mechanism should have overhead, while 676ns is acceptable, but 88152
> is not.
> probe kernel.function("arch_cpu_idle_enter").call
> t_start[cpu()] = gettimeofday_ns()
> probe kernel.function("local_touch_nmi").call
> t_end <<< gettimeofday_ns() - t_start[cpu()]
A couple of things come to mind. Use of gettimeofday_ns() function uses
a software-estimated real-time clock, which may not be steady enough for
high-grained measurements like this. Consider using get_cycles() or the
functions in the [man tapset::timestamp_monotonic] tapset.
Another possibility is jitter like caching effects within the kernel due
to activity elsewhere. The average is pretty low. Consider printing a
histogram of t_end, or (if using git systemtap) its @variance.
Another possibility is contention over the t_start[] variable, if
multiple processors are running this region of code, so trigger the
systemtap probes concurrently. systemtap automatically locks such
global variables, esp. if they contain non-aggregate values like the
scalar timestamps.
Consider using "stap -t FOO.stp" to have the tool print internal
estimates of its own probes' runtimes. That would include lock
contention, but exclude kernel-side overheads like the code involved in
the its kprobes machinery.
- FChE
next prev parent reply other threads:[~2016-11-25 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 16:07 Aubrey Li
2016-11-25 17:22 ` Frank Ch. Eigler [this message]
2016-11-26 6:18 ` Aubrey Li
2016-11-28 19:19 ` Frank Ch. Eigler
2016-11-29 3:31 ` Aubrey Li
2016-11-29 19:21 ` Josh Stone
2016-12-01 18:47 ` Cody Santing
[not found] ` <CAGPKeUKm9EZZxL=MHZX9_0N5SUYX291mJMTCExYSspRceJgrxg@mail.gmail.com>
2016-12-12 17:07 ` Fwd: " Cody Santing
2016-12-12 17:43 ` Frank Ch. Eigler
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=y0m1sxzpj9i.fsf@fche.csb \
--to=fche@redhat.com \
--cc=aubreylee@gmail.com \
--cc=systemtap@sourceware.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).