[lkml]   [2005]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.11-rc1-mm1
    Andrew Morton <> 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.

    Advantage of this would be that it had no impact on fast paths
    unless enabled (LTT slows down a kernel quite considerable just
    by compiling it in)

    > As does relayfs, IMO. It seems to need some regularised way in which a
    > userspace relayfs client can tell relayfs what file(s) to use. LTT is
    > currently using some ghastly stick-a-pathname-in-/proc thing. Relayfs
    > should provide this service.
    > relayfs needs a closer look too. A lot of advanced instrumentation
    > projects seem to require it, but none of them have been merged. Lots of
    > people say "use netlink instead" and lots of other people say "err, we think
    > relayfs is better". This is a discussion which needs to be had.

    imho relayfs and netlink are for completely problem spaces.
    relayfs is for relaying a lot of data quickly (e.g. for kernel
    instrumentation). There it fills a niche that printk doesn't fill
    (since it's too slow). netlink is quite slow (allocates data for each
    event, does lots of other gunk), but an useful extensible format
    for low frequency events.

    For the problems that relayfs solves netlink is totally unusable
    due to low efficiency (you could as well use printk, but that is
    also to slow). I think a low overhead logging mechanism is very
    much needed, because I find myself reinventing it quite often
    when I need to debug some timing sensitive problem. Trying to
    tackle these with printk is hopeless because it changes timing too much.

    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

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.042 / U:22.484 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site