[ltt-dev] Usage of relayfs specific operations in generic code

[Mathieu Desnoyers]

* 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:

* synchronization

ltt/ltt-relay-lockless.c
ltt/ltt-relay-lockless.h

* allocation

ltt/ltt-relay-alloc.c
include/linux/ltt-relay.h

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.

Mathieu

> 
> How does that sound ?
> 
> Mathieu
> 
> 
> >
> > 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
> 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