linux-kernel - Re: [RFC][PATCH] convert block trace points to TRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 May 2009 10:35:39 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Theodore Ts'o <tytso@....edu>,
	Steven Whitehouse <swhiteho@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH] convert block trace points to TRACE_EVENT()


* Li Zefan <lizf@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/