From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [git pull] latency tracer
Date: Sat, 9 Feb 2008 08:01:44 +0100 [thread overview]
Message-ID: <20080209070144.GA21046@elte.hu> (raw)
In-Reply-To: <20080208214522.GA31101@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> It does include one very interesting new feature that deserves to be
> mentioned outside of the shortlog: 'dynamic ftrace' - which is a
> transparent kernel-image-patcher mechanism that lazily patches out
> mcount callsites from all functions that get executed. [if tracing is
> disabled] These patched out callsites are remembered, and are patched
> back in when tracing is enabled.
>
> This technique does not just accelelerate the "tracing disabled" case
> enormously, we were in fact unable to measure _any_ performance
> difference (within noise) between an mcount-enabled dyn-ftrace [but
> tracing-disabled] and a vanilla kernel (!), on modern CPUs.
hot off the presses: Steve has just finished doing a complete set of
lmbench and hbackbench runs (on 2.8GHz Xeons, dual socket). The
comparison results are at:
http://rostedt.homelinux.com/dyn-ftrace-lmbench/lmbench-table
the results show zero lmbench/hackbench overhead from dyn-ftrace (with
thousands of functions instrumented) apart of the usual lmbench jitter.
The core kernel results for example [these used to be rather sensitive
on mcount overhead]:
Host OS Mhz null null open slct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
ftrace-jm Linux 2.6.24 2783 0.65 0.74 4.74 6.96 5.28 0.76 4.29 290. 866. 2626
ftrace-no Linux 2.6.24 2784 0.65 0.74 4.75 7.14 5.31 0.76 3.92 282. 837. 2591
no-patche Linux 2.6.24 2786 0.64 0.71 4.86 7.10 5.34 0.78 3.89 283. 829. 2572
patched-n Linux 2.6.24 2784 0.64 0.71 4.72 6.98 5.35 0.78 3.94 284. 832. 2582
"ftrace-jm": dyn-ftrace, 2-byte JMPs patched in the mcount callsite
"ftrace-no": dyn-ftrace, 5-byte NOPs patched in (devel patch, not in
this pull request)
"no-patche": no patches [vanilla Linus -git kernel]
"patched-n": patched with the ftrace tree, all tracer options off
i can see an outlier in the "Create" results - that's noise i think
because the patched+options-off kernel is in essence the same as
vanilla. "File reread" is noisy and unreliable as ever. 16-task
ctx-switch results are noisy too (especially the 64k working set ones) -
this is a HT system hence the multi-threaded results are fundamentally
noisy due to sibling interaction.
The hackbench results look good too.
enabling full tracing of all the tens of thousands of kernel functions
makes things measurably slower - but that is expected. (filtered
patching of a user-selected list of function names is an upcoming
feature)
the full raw results are at:
http://rostedt.homelinux.com/dyn-ftrace-lmbench/
Ingo
next prev parent reply other threads:[~2008-02-09 7:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 21:45 [git pull] latency tracer Ingo Molnar
2008-02-09 7:01 ` Ingo Molnar [this message]
2008-02-09 7:23 ` Andrew Morton
2008-02-09 7:37 ` Ingo Molnar
2008-02-09 8:05 ` Andrew Morton
2008-02-09 14:21 ` Ingo Molnar
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=20080209070144.GA21046@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.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