From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9776 invoked by alias); 9 Jun 2009 00:02:25 -0000 Received: (qmail 8840 invoked by uid 9586); 9 Jun 2009 00:02:23 -0000 Date: Tue, 09 Jun 2009 00:02:00 -0000 Message-ID: <20090609000222.8614.qmail@sourceware.org> 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 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: a77245e55075e1b756b51a5226483fe5e618940e X-Git-Newrev: f517ee24c58413f7de89ede71c728579c12ace5b Mailing-List: contact systemtap-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-cvs-owner@sourceware.org List-Archive: Reply-To: systemtap@sourceware.org X-SW-Source: 2009-q2/txt/msg00291.txt.bz2 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 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 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