From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21419 invoked by alias); 30 Jun 2008 20:00:34 -0000 Received: (qmail 21403 invoked by uid 22791); 30 Jun 2008 20:00:32 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,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; Mon, 30 Jun 2008 20:00:13 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5UK0BVP011453 for ; Mon, 30 Jun 2008 16:00:11 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [10.16.255.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5UK09H3030162; Mon, 30 Jun 2008 16:00:10 -0400 Received: from [10.16.3.219] (dhcp-100-3-219.bos.redhat.com [10.16.3.219]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m5UK08Lp009495; Mon, 30 Jun 2008 16:00:09 -0400 Message-ID: <48693AFB.1020304@redhat.com> Date: Mon, 30 Jun 2008 20:17:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Mathieu Desnoyers CC: KOSAKI Motohiro , Takashi Nishiie , "'Alexey Dobriyan'" , "'Peter Zijlstra'" , "'Steven Rostedt'" , "'Frank Ch. Eigler'" , "'Ingo Molnar'" , "'LKML'" , "'systemtap-ml'" , "'Hideo AOKI'" Subject: Re: [RFC PATCH] Kernel Tracepoints References: <007601c8d5ca$18fa0e10$4aee2a30$@css.fujitsu.com> <48611B03.1000003@redhat.com> <20080625011951.D83E.KOSAKI.MOTOHIRO@jp.fujitsu.com> <48612879.5090809@redhat.com> <20080625235214.GA14249@Krystal> <486403F0.4020801@redhat.com> <20080627133009.GC13751@Krystal> <48655464.5040000@redhat.com> <20080630154002.GE17388@Krystal> In-Reply-To: <20080630154002.GE17388@Krystal> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00809.txt.bz2 Hi Mathieu, Mathieu Desnoyers wrote: > * Masami Hiramatsu (mhiramat@redhat.com) wrote: >> Mathieu Desnoyers wrote: >>> * Masami Hiramatsu (mhiramat@redhat.com) wrote: >>> > >>>>> Implementation of kernel tracepoints. Inspired from the Linux Kernel Markers. >>>> What would you think redesigning markers on tracepoints? because most of the >>>> logic (scaning sections, multiple probe and activation) seems very similar >>>> to markers. >>>> >>> We could, although markers, because they use var args, allow to put the >>> iteration on the multi probe array out-of-line. Tracepoints cannot >>> afford this and the iteration must be done at the initial call-site. >>> >>> From what I see in your proposal, it's mostly to extract the if() call() >>> code from the inner __trace_mark() macro and to put it in a separate >>> macro, am I correct ? This would make the macro more readable. >> Sure, I think marker and tracepoint can share below functions; >> - definition of static local variables in specific sections > > Given that we could want to keep activation of tracepoints and markers > separate (so they don't share the same namespace), declaring the static > variables in separated sections seems to make sense to me. Sorry, I'm not sure what is "separate activation". As far as I can see, both tracepoints and markers are activated when its probe handlers are registered on each tracepoint/marker. Aren't it separated? I did not mean integrating registering interfaces, but I think that they can share base(internal) functions. for example, both of them has XXX_update_range/_module_XXX_update etc. IMHO, current code is not so good for maintenance. there are many code duplications (ex. kernel/module.c, I think that both of them (and imv too?) can share the code for handling its section and iterating entries). I'm not sure those duplications are acceptable. >> - probe activation code (if() call()) >> - multi probe handling > > Hrm, the thing here is that because markers allow to do the iteration on > the multiple probe callbacks within an internal wrapper (instead of > doing it on-site as in the tracepoints), it allows to do some further > optimizations (less memory allocation and less pointer dereference in > the single probe case, not having to prepare the va_args in the > MARK_NOARGS case) which are only done because it does not have to add > code to the instrumentation site. However, tracepoints cannot have such > "generic" wrapper and we have to do the iteration on callbacks in the > code added to the instrumented object. Therefore, I keep it as small as > possible in terms of bytes of instructions. OK, I see. So, __tracepoint_block() macro can specify handler function. what would you think about it? Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@redhat.com