All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Jens Axboe <jens.axboe@oracle.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tom Zanussi <tzanussi@gmail.com>, "Theodore Ts'o" <tytso@mit.edu>,
	Steven Whitehouse <swhiteho@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] convert block trace points to TRACE_EVENT()
Date: Tue, 19 May 2009 14:11:55 +0800	[thread overview]
Message-ID: <4A124DAB.109@cn.fujitsu.com> (raw)
In-Reply-To: <20090518130514.GB4704@nowhere>

Frederic Weisbecker wrote:
> On Thu, May 14, 2009 at 02:20:03PM +0800, Li Zefan wrote:
>> TRACE_EVENT is a more generic way to define tracepoints. Doing so adds
>> these new capabilities to this tracepoint:
>>
>>   - zero-copy and per-cpu splice() tracing
>>   - binary tracing without printf overhead
>>   - structured logging records exposed under /debug/tracing/events
>>   - trace events embedded in function tracer output and other plugins
>>   - user-defined, per tracepoint filter expressions
>>   ...
>>
>> Cons and problems:
>>
>>   - no dev_t info for the output of plug, unplug_timer and unplug_io events.
>>     no dev_t info for getrq and sleeprq events if bio == NULL.
>>     no dev_t info for rq_abort,...,rq_requeue events if rq->rq_disk == NULL.
>>
>>   - for large packet commands, only 16 bytes of the command will be output.
>>     Because TRACE_EVENT doesn't support dynamic-sized arrays, though it
>>     supports dynamic-sized strings.
>>
>>   - a packet command is converted to a string in TP_assign, not TP_print.
>>     While blktrace do the convertion just before output.
>>
>>   - in blktrace, an event can have 2 different print formats, but a TRACE_EVENT
>>     has a unique format. (see the output of getrq and rq_insert)
> 
> I'm starting to think it would be nice to choose between several outputs
> in a trace event.
> Ie: perhaps we need a kind of per event flag, something simple, just to
> choose between several TP_printk output. Not sure how much it would
> (non) trivial to implement though...
> 

If a trace event wants several TP_printk output, probably it wants different
structs of trace entry, otherwise we'll be wasting memory.


  reply	other threads:[~2009-05-19  6:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14  6:20 [RFC][PATCH] convert block trace points to TRACE_EVENT() Li Zefan
2009-05-18  8:35 ` Ingo Molnar
2009-05-19  6:04   ` Li Zefan
2009-05-18 13:05 ` Frederic Weisbecker
2009-05-19  6:11   ` Li Zefan [this message]
2009-05-19 12:59 ` Jeff Moyer
2009-05-19 13:08   ` Christoph Hellwig
2009-05-19 15:49     ` FUJITA Tomonori
2009-05-19 17:33       ` Jens Axboe
2009-05-20  8:38     ` Li Zefan
2009-05-23 12:40       ` Christoph Hellwig
2009-05-24  5:15         ` KOSAKI Motohiro
2009-05-24  8:57           ` Christoph Hellwig
2009-05-24 13:47             ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A124DAB.109@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=fweisbec@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=swhiteho@redhat.com \
    --cc=tytso@mit.edu \
    --cc=tzanussi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.