public inbox for systemtap-cvs@sourceware.org help / color / mirror / Atom feed
From: jistone@sourceware.org To: systemtap-cvs@sourceware.org Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9.7-198-gf517ee2 Date: Tue, 09 Jun 2009 00:02:00 -0000 [thread overview] Message-ID: <20090609000222.8614.qmail@sourceware.org> (raw) This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "systemtap: system-wide probe/trace tool". The branch, master has been updated via f517ee24c58413f7de89ede71c728579c12ace5b (commit) via 0e14e0793ffb891bccd465cf518480685e3cd49e (commit) from a77245e55075e1b756b51a5226483fe5e618940e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f517ee24c58413f7de89ede71c728579c12ace5b Author: Josh Stone <jistone@redhat.com> Date: Mon Jun 8 16:37:00 2009 -0700 Remove dwflpp::default_name It was just a basic NULL check, but creating its string temporaries was causing a fair slowdown. Removing this function and adjusting the callers shaves ~5% off the syscall.* elaboration time. commit 0e14e0793ffb891bccd465cf518480685e3cd49e Author: Josh Stone <jistone@redhat.com> Date: Mon Jun 8 15:36:42 2009 -0700 Let query_module abort early for simple matches query_module was already returning DW_CB_ABORT when a simple match was found, but dwflpp::iterate_over_modules was ignoring that and instead forcing the module loop to restart. The only way out of the loop was with the pending_interrupts flag, which is only for signalled interrupts. Now iterate_over_modules will only attempt the dwfl_getmodules loop once, since that loop will only abort if the CB returns DW_CB_ABORT. Then query_module is also modified to return ABORT if pending_interrupts is flagged. My trusty test, stap -l syscall.*, is nearly 2x faster with this change. Empirically, I found that the kernel object is always the first "module" returned, so the syscall probepoints always gets to short-circuit the loop right away. ----------------------------------------------------------------------- Summary of changes: dwflpp.cxx | 28 ++++++---------------------- dwflpp.h | 2 -- tapsets.cxx | 6 +++--- 3 files changed, 9 insertions(+), 27 deletions(-) hooks/post-receive -- systemtap: system-wide probe/trace tool
reply other threads:[~2009-06-09 0:02 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20090609000222.8614.qmail@sourceware.org \ --to=jistone@sourceware.org \ --cc=systemtap-cvs@sourceware.org \ --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: linkBe 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).