[ltt-dev] Usage of relayfs specific operations in generic code
compudj at krystal.dyndns.org
Sat Nov 21 12:16:38 EST 2009
* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Viktor Rosendahl (viktor.rosendahl at nokia.com) wrote:
> > Hello,
> Hi Viktor,
> > I was trying to implement support for a Nokia specific HW transport when
> > I came across this lovely snippet of code in ltt-serialize.c:
> > /* FIXME : could probably encapsulate transport better. */
> > buf = ((struct rchan *)channel->trans_channel_data)->buf[cpu];
> > /* Out-of-order write : header and data */
> > buf_offset = ltt_write_event_header(trace,
> > channel, buf, buf_offset,
> > eID, data_size, tsc, rflags);
> > ltt_write_event_data(buf, buf_offset, &closure,
> > serialize_private,
> > largest_align, fmt, &args_copy);
> > It could be mentioned that both ltt_write_event_header() and
> > ltt_write_event_data() both uses relayfs specific functions. Also, I
> > think that the rchan struct is more or less specific to relayfs.
> LTTng has stopped using relayfs a long time ago. We have all the
> locking, allocation and vfs interface code within the ltt/ directory.
> Note that I refer to the term "transport" as a combination of:
> - locking scheme
> - allocation scheme
> - interface (e.g. vfs)
> > To me this seems like the generic LTTng code is using relayfs specific
> > operations to write an event header and the data.
> > Now I wonder, what is the proper way of tackling this problem?
> A bit of history here:
> In the past, LTTng transports could be chosen by specifying a callback
> that would be called for space reservation and commit. This is however
> too slow, as it adds unnecessary function calls to the tracing hot path.
> Currently, the way this is done is by allowing to select the LTTng
> locking scheme at build time (e.g. lockless, irqoff, spinlock+irqoff).
> Recently, I dropped all schemes except lockless, because it was faster
> to do lots of code changes in just one scheme.
> Eventually, the goal is to permit to compile various kernel modules for
> the different transports (and select any of these at runtime), _but_ not
> require extra function calls. This will lead to duplication of some
> objects, which will be compiled in more than one module with slightly
> different parameters, but given we typically only use one transport at a
> time, this should not be a problem.
> So what I propose is that you work on the latest LTTng tree, changing
> ltt-relay-alloc to suit your needs, possibly copying this file and doing
> your work in a different C file, that could be chosen to replace
> ltt-relay-alloc with the proper CONFIG option. If you need some extra
> hooks to be called by ltt-relay-lockless.c to, for example, flush the
> data out when a subbuffer is filled, then we can work on that together.
> This first step would allow you to choose your own transport at build
> time (the standard transport would not be available anymore). Then, when
> we do the integration, we can work together to ensure that we allow
> kernel modules for both transports to be compiled and we allow to select
> between those at runtime.
BTW, you will also need to copy include/linux/ltt-relay.h and specialize
it for your needs.
How it currently works:
In the larger scheme of things, we will eventually have to move
include/linux/ltt-relay.h to ltt/ so it can be used for one specific
type of transport.
> How does that sound ?
> > Should I add a couple of transport specific operations to the
> > ltt_trace_ops struct and try to move the relayfs specific functionality
> > into ltt-relay.c and ltt-relay-locked.c ?
> > Are there any other places where transport relayfs code is used in those
> > parts of LTTng that one would expect to be generic ?
> > Any other hints ?
> > BTW, I am currently using lttng-0.88 on a 2.6.28 based kernel.However, I
> > checked that the same problem is still present in the very latest LTTng
> > in the git repository.
> > Also, I saw that the problem was introduced in
> > patch-2.6.27-rc7-lttng-0.27.tar.gz, which was released in October 2008.
> > In other words, this issue has been present in the LTTng code base for
> > about a year, if I am not mistaken.
> > best regards,
> > Viktor
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
More information about the lttng-dev