linux-kernel - LTTng 0.27, vmap-less buffering and splice()

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-next>] [day] [month] [year] [list]

Message-ID: <20081002060626.GD7676@Krystal>
Date:	Thu, 2 Oct 2008 02:06:26 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	ltt-dev@...ts.casi.polymtl.ca
Cc:	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: LTTng 0.27, vmap-less buffering and splice()

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