From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756761AbbDVCaW (ORCPT ); Tue, 21 Apr 2015 22:30:22 -0400 Received: from mail03v-smtp01.fnal.gov ([131.225.199.28]:16921 "EHLO ex-smtp.fnal.gov" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752613AbbDVCaU (ORCPT ); Tue, 21 Apr 2015 22:30:20 -0400 X-Greylist: delayed 321 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Apr 2015 22:30:20 EDT Message-ID: <55370673.60504@fnal.gov> Date: Tue, 21 Apr 2015 21:24:51 -0500 From: Ron Rechenmacher Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steven Rostedt CC: Christoph Hellwig , , Arnaldo Carvalho de Melo , Arjan van de Ven , Namhyung Kim Subject: Re: [PATCH] tracing: Export key trace event symbols References: <553571C3.1060505@fnal.gov> <20150421061034.GA9253@infradead.org> <55363CDC.4000305@fnal.gov> <20150421122202.GA8708@infradead.org> <55364CF4.2090600@fnal.gov> <20150421132355.GA18161@infradead.org> <55365002.4010707@fnal.gov> <20150421095310.12370f88@gandalf.local.home> <55366609.4020709@fnal.gov> <20150421114931.63fd343d@gandalf.local.home> <5536CDF1.2020801@fnal.gov> <20150421184446.7b63cbec@gandalf.local.home> In-Reply-To: <20150421184446.7b63cbec@gandalf.local.home> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [99.141.209.99] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt wrote on 04/21/15 17:44: > > [ Added a bunch of people that use perf ;-) ] > Thanks. I hope they can help me get the patch accepted. [snip] >>> >>> +/* >>> + * Allow modules to register additional trace routines >>> + */ >>> +EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_entry); >>> +EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_exit); >>> + >>> >>> Instead of just saying "Allow modules to register additional trace >>> routines", please explain what its used for. What are you measuring >>> externally? Just the timings of the interrupts? >> >> How about "Allow for module (internal or external) to register trace function which >> shows (or measures) interactions with user-space executables more directly. Knowing >> when interrupts happen and how they can subtly impact user-space application timing >> is important in some application." >> >>> >>> I'm also curious to know why ftrace isn't good enough. >> >> ftrace (if one considers ltt-ng) is probably capable of doing what my trace does >> except that the timestamp is not TOD (Time Of Day) -- but probably/maybe could >> be made to do so??? >> >> It's a matter of complexity or "start up cost" (or entry barrier). >> >> I'm not the best at articulating all there is to TRACE succinctly, but lets >> start with the fact that the user-space component of TRACE is basically just a header >> file that defines the TRACE printf-like macro and handles the initialization which is >> basically mmap-ing a file (as a trace buffer (with control structure)) and is, >> for the most part, Unix OS independent. > > Heh, that sounds like the perf interface. Have you thought about using > that instead? > > Look at what PowerTop does: https://01.org/powertop > > You can use the perf interface to mmap a memory buffer and read the > data in its raw format. To parse the data, you need to read the format I've looked at the above reference briefly and it appears that user-space would be mmapping the buffer read-only. Is that correct? I've also looked at lttng and I've said before, the "start-up cost" is too high. My TRACE module creates the virtual file and allows the user-space program(s) to mmap a portion of it read-only (to protect the kernel) and then the buffer portion read-write - so, yes, any user-space program _could_ simply scribble over the buffer-portion, but what they usually end up doing it _writing_ their traces into the appropriate "slot" memory along side of slots that the kernel could be writing the key event TRACEs to. I'm not trying to promote the use of my TRACE, I'm just trying to show that there is a set of valid reasons (current and potential future) for accepting my patch. > files in /sys/kernel/debug/tracing/events, but there's a library that > does that. Unfortunately, that library isn't in distros yet (we really > need to get that done). But you can just copy the code from the kernel > source tree from tools/lib/traceevents/ and use that as perf does (as > well as powertop does too). > > The format files tells you how to get the data from the raw binary > format. > > If you use the perf interface, you can have userspace tools do custom > things with the events as they happen. This may make your utility more > robust in the long run. > > I'd be happy to help you understand how to use the traceevent library. I > don't use the perf interface, but you can get examples from the > PowerTop code. I'd rather not get into the "you should stop doing your thing and just/only do something else" mode, if you don't mind. As I've said before, I believe my TRACEing is just the right level of complexity for the total system analysis that I do and I have been periodically checking/searching what's out there. A college of mine and I actually used perf, just today, to gain an understanding of what is going on in our "Nova data acquistion" system at fermilab. While it was useful, it is not a replacement for TRACE. Thanks, Ron > > -- Steve > [snip] -- Ron Rechenmacher Engineer Fermi National Accelerator Laboratory Batavia, IL 60510