lkml.org 
[lkml]   [2005]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.11-rc1-mm1
Hello,

I’m a developer of yet another kernel tracer, LKST. I and co-developers
are very glad to hear that LTT was merged into -mm tree and to talk
about the kernel tracer on this ML. Because we think that the kernel
event tracer is useful to debug Linux systems, and to improve the kernel
reliability.

Andi Kleen wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
>>- Added the Linux Trace Toolkit (and hence relayfs). Mainly because I
>> haven't yet taken as close a look at LTT as I should have. Probably neither
>> have you.
>
>
> I think it would be better to have a standard set of kprobes instead
> of all the ugly LTT hooks. kprobes could then log to relayfs or another
> fast logging mechanism.

I agree.
I’m interested in kprobes. Currently, LKST can switch off and on each
hook. But, even if a hook was disabled, there is a little overhead-time
(one conditional-jump instruction should be executed). I think
kprobes-based hooks can completely remove this overhead-time. Moreover,
kprobes-based hooks can be inserted dynamically into the code-point
specified by user. This feature is greatly useful for debugging. So, I
have an idea to renew LKST to kprobes-based hooks.
Also, I’m developing a prototype implementation.


> The problem relayfs has IMHO is that it is too complicated. It
> seems to either suffer from a overfull specification or second system
> effect. There are lots of different options to do everything,
> instead of a nice simple fast path that does one thing efficiently.
> IMHO before merging it should go through a diet and only keep
> the paths that are actually needed and dropping a lot of the current
> baggage.
>
> Preferably that would be only the fastest options (extremly simple
> per CPU buffer with inlined fast path that drop data on buffer overflow),
> with leaving out anything more complicated. My ideal is something
> like the old SGI ktrace which was an extremly simple mechanism
> to do lockless per CPU logging of binary data efficiently and
> reading that from a user daemon.

LKST’s logging buffer is (much) simpler than relayfs. It is just the
linked-perCPU-buffer.

If you are interested in this, please try LKST.


--
Masami HIRAMATSU

Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.613 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site