Re: [RFC][PATCH] convert block trace points to TRACE_EVENT()

[Ingo Molnar <mingo@elte.hu>]

* Li Zefan <lizf@cn.fujitsu.com> 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
>   ...

Nice!

> 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.

Cannot we output the numeric major:minor pairs?

>   - 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.

Couldnt we do a memcpy instead of the snprintf() in __dump_pdu()? We 
dont actually interpret the bytes there. We could extend the 
in-kernel printk format with a 'dump raw memory in hex' type of 
format specifier.

OTOH, packet requests are rather rare, right? So going to ASCII 
there results in a simpler interface. In the !blk_pc_request(rq) 
common case we just return early without any snprintf overhead.

>   - 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)

Is this a problem?

I think a good way forward would be to benchmark the ioctl versus 
the splice based TRACE_EVENT tracing (via some artificially high 
rate event, to push things), and see where we are right now in terms 
of overhead.

	Ingo