public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: ltt-dev@lists.casi.polymtl.ca
Cc: linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>
Subject: LTTng 0.27, vmap-less buffering and splice()
Date: Thu, 2 Oct 2008 02:06:26 -0400	[thread overview]
Message-ID: <20081002060626.GD7676@Krystal> (raw)

Hi,

I have reworked the underlying buffering mechanism LTTng uses in the
past week. I took "relay", changed its vmap() buffers for my own linked
list of buffers (not vmaped), made read/write wrappers which support
writing data larger than a page size and writing across page boundaries,
and finally managed to create a splice_read file operation which
supports that. I finally changed lttd to make it use splice() instead of
a mmap() and... it worked! :-) (after a bit a debugging, clearly)

This is all in LTTng 0.27 and ltt-control 0.53 (for the lttd part).
As this is an important change, testing is very welcome. If you are
interested in looking in the inner details of the buffering mechanism I
just did, you might also want to enable the "check for random buffer
access" option in the menuconfig. It will generate warnings when offset
accesses more than a page away from the previous done is requested by
the client. Cases such as large data write and reentrancy over the
tracer code will generate a few "cache misses", but it's supposed to be
rare, and therefore not a performance concern. This self-checking
feature has proven to be very useful in the early development stages,
and I think it's also useful if any other tracer client want to use it :
it helps finding lack of reference locality a tracer client might have.

I am also very interested in getting numbers comparing the performance
of the new buffering infrastructure with the previous one. Having much
less TLB impact should improve performance.

It's all available in the git tree :
http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=summary

And the userspace packages available at http://ltt.polymtl.ca (see the
"QUICKSTART")

Cheers,

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

             reply	other threads:[~2008-10-02  6:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-02  6:06 Mathieu Desnoyers [this message]
2008-10-03 16:39 ` [ltt-dev] LTTng 0.27, vmap-less buffering and splice() Mathieu Desnoyers

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=20081002060626.GD7676@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    /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