From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753512AbYKZLcv (ORCPT ); Wed, 26 Nov 2008 06:32:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752076AbYKZLcn (ORCPT ); Wed, 26 Nov 2008 06:32:43 -0500 Received: from mail-qy0-f11.google.com ([209.85.221.11]:51727 "EHLO mail-qy0-f11.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbYKZLcm (ORCPT ); Wed, 26 Nov 2008 06:32:42 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aSSXe81JqDbjyVid7kzmHJ2AIFVPjnOJuV7+OetyBfXneHfaK+bPh0pcjAO8h69+FR OvqH8CwpqOm5qeytSk/BqbYDWOPCR25LP72cKg+zyI1YsTnQM72s1FsVeWWe/K+tovA9 mntI2Z0EgFnLoVTV1hZx8TAWqozCtHzybkj2Y= Message-ID: Date: Wed, 26 Nov 2008 12:32:41 +0100 From: "=?ISO-8859-1?Q?Fr=E9d=E9ric_Weisbecker?=" To: "Steven Rostedt" Subject: Re: [PATCH] tracing/function-return-tracer: set a more human readable output Cc: "Ingo Molnar" , "Linux Kernel" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <492C90E5.8070907@gmail.com> <20081126003936.GA26937@elte.hu> <20081126020459.GA16374@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2008/11/26 Steven Rostedt : > > On Wed, 26 Nov 2008, Ingo Molnar wrote: >> >> The changes would be: >> >> 1) Compression of non-nested calls into a single line. >> >> Implementing this probably necessiates some trickery with the >> ring-buffer: we'd have to look at the next entry as well and see >> whether it closes the function call. > > The latency_trace file does this already: > > You can look into the trace buffer without moving it with: > > entry = ring_buffer_iter_peek(iter->buffer_iter[iter->cpu], &ts); > > where, ts will give you the time stamp, it can be NULL if you do not care. > > When your print function is called, the item in the ring buffer has > already been consumed. So the peek will give you the next item in the ring > buffer. >> >> 2) Adding a closing ';' semicolon to single-line calls. It's the C >> syntax and i'm missing it :-) >> >> 3) The first column: single-character visual shortcuts for "overhead". >> This is a concept we used in the -rt tracer and it still lives in >> the latency tracer bits of ftrace and is quite useful: >> >> '+' means "overhead spike": overhead is above 10 usecs. >> '!' means "large overhead": overhead is above 100 usecs. >> >> These give at-a-glance hotspot analysis - hotspots are easier to >> miss as pure numbers. > > The latency_trace file has this too. And it uses the above peek to figure > it out ;-) That's right, the latency_trace does it. But it is based on a ring-buffer entry timestamp. I wanted to use ring-buffer entry timestamp, but it would be hard to calculate the duration since the return trace of a function doesn't often follow immediately its entry trace. And I can't reuse lat_print_timestamp() because I need the nsec remaining part.... This is too specific to reuse latency_trace...