From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1869 invoked by alias); 14 May 2006 20:26:31 -0000 Received: (qmail 1862 invoked by uid 22791); 14 May 2006 20:26:30 -0000 X-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_20,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 14 May 2006 20:25:37 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k4EKPUYZ003442; Sun, 14 May 2006 16:25:30 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k4EKPTtX027898; Sun, 14 May 2006 16:25:29 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id k4EKPTeZ024015; Sun, 14 May 2006 16:25:29 -0400 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 699C380004C; Sun, 14 May 2006 16:25:29 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id k4EKPTdC013147; Sun, 14 May 2006 16:25:29 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id k4EKPSWU013146; Sun, 14 May 2006 16:25:28 -0400 Date: Sun, 14 May 2006 20:26:00 -0000 From: "Frank Ch. Eigler" To: Li Guanglei Cc: systemtap@sourceware.org Subject: Re: get the mapping of Message-ID: <20060514202528.GG24772@redhat.com> References: <44629BC3.7030505@cn.ibm.com> <4464B262.7030000@us.ibm.com> <20060512161204.GB12528@redhat.com> <4465882B.3070002@cn.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4465882B.3070002@cn.ibm.com> User-Agent: Mutt/1.4.1i Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00403.txt.bz2 Hi - guanglei wrote: > [...] > But one disadvantage is that if using "syscall.*", then every syscall > will use a different function to be its probe handler. There are two separate opportunities for improvement here, and both of them are going to get some attention. First, a lot of essentially duplicated registration, unregistration, and entry routines are being generated. These can be collapsed into one triplet of functions per type (one for all kprobes, one for all kretprobes, etc.). This will remove hundreds of functions of the "syscall.*"-originated C code, and should make a drastic difference as to performance. Second, probe handlers constructed from distinct probe/alias bodies may be collapsed, if they turn out to be equivalent after optimization. One might think of it as a generalization of graydon's "flavour" calculations in tapsets.cxx. Together, these two tapset-level optimizations should bring the "abstraction penalty" way down. > [Regarding parsing CONTEXT->probe_point: ...] As discovered in the > former analysis of LKET, strpbrk() is one of the most costly > operations. It is a kernel function and is called by strsep() to get > the current syscall name. I use another way to get the syscall > name: [...] It may be worth addressing this a totally different way too. The translator could provide another variable, a sibling of CONTEXT->probe_point. It would contains the equivalent of probefunc(), at least for those probes that have a "synchronous" binding to a PC address, which kprobes-based ones do. It could be statically initialized the same way as probe_point, and the probefunc() tapset function could be extended to look at that field first. No strpbrk or iteration at all then. - FChE