From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, Tom Zanussi <zanussi@us.ibm.com>,
ltt-dev@shafik.org
Subject: blktrace daemon vs LTTng lttd
Date: Tue, 21 Feb 2006 22:00:44 -0500 [thread overview]
Message-ID: <20060222030044.GB17987@Krystal> (raw)
Hi M. Axboe,
Tom Zanussi just informed me of your work of blktrace. I think that some aspects
of our respective projects (mine being LTTng) shows resemblances.
LTTng is a system wide tracer that aims at tracing programs/librairies and the
kernel. There is a version currently available at http://ltt.polymtl.ca. Is has
a viewer counterpart (LTTV) that analyses and show graphically the traces takes
by LTTng.
I just looked at the blktrace code, and here are some parts we share :
- We both use RelayFS for data transfer to user space.
- We both need to get highly precise timestamps.
Where LTTng might have more constraints is on the performance and reentrancy
side : my tracer is NMI reentrant (using atomic operations) and must be able to
dump data at a rate high enough to sustain a loopback ping flood (with
interrupts logged). Time precision must permit to reorder events occuring very
closely on two different CPUs.
I already developed a multithreaded daemon (lttd) that generically reads the
RelayFS channels : it uses mmap() and 4 ioctl() to control the channel
buffers. I just discussed it with Tom Zanussi in the following thread :
http://www.listserv.shafik.org/pipermail/ltt-dev/2006-February/001245.html
Here is the argumentation I gave to justify the use of ioctl() for RelayFS
channels (in the same discussion) :
http://www.listserv.shafik.org/pipermail/ltt-dev/2006-February/001247.html
I suggest to integrate my ioctl addition to the RelayFS channels so they can be
used very efficiently with both mmap() and ioctl() to control the reader.
It would be trivial to use send() instead of write() to adapt lttd to the
networked case.
Using mmap() and write() instead or read() and write() would eliminate the
extra copy blktrace is doing when it writes to disk.
What do you think about it ?
On another point, I looked at your timekeeping in blktrace and I think you could
gain precision by using a monotonic clock instead of do_gettimeofday (which is
altered by NTP).
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next reply other threads:[~2006-02-22 3:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 3:00 Mathieu Desnoyers [this message]
2006-02-22 7:48 ` Jens Axboe
2006-02-22 14:24 ` Mathieu Desnoyers
2006-02-22 14:51 ` Jens Axboe
2006-02-22 15:19 ` Mathieu Desnoyers
2006-02-22 15:39 ` Jens Axboe
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=20060222030044.GB17987@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=zanussi@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®