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:	Tue, 19 May 2009 08:59:29 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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> writes:

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

I'm not sure I'm comfortable with this.  Having had to diagnose
performance problems using blktrace, I find the dev_t information for
plugs and unplugs especially interesting.  Maybe we can still figure
this out given the context in the trace, though.  Can you comment on
that?

>     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)
>
>
> Following are some comparisons between TRACE_EVENT and blktrace:
>
> plug:
>   kjournald-480   [000]   303.084981: block_plug: [kjournald]
>   kjournald-480   [000]   303.084981:   8,0    P   N [kjournald]

I'm not a big fan of having to change my scripts!  Why did you switch
from the single letter output to the verbose strings?  Am I just being a
curmudgeon?

I have one further question, which will expose my ignorance on this
implementation.  Would the proposed patch change the information
available to the blktrace utility, or is this just for users such as
systemtap?

Cheers,
Jeff
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ