This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Changes to systemtap transport

I'm about to check in my rewrite of the systemtap transport.  The will
be mostly invisible to users, with one proposed exception.

The bulkmode (relayfs) options seemed overly complex and I have
simplified them. If you are writing apps which use it, I would like your

In the old system, "stap -b" would transfer data percpu, then when
finished merge the output into a single stream.  Anyone actually using
this? It seems useless especially in the new transport where stream mode
is as fast as bulk mode (probably except on NUMA systems).  

"stap -bM" would create percpu files "stpd_cpuN" Those files are in no
particular format and it is entirely up to the application (tapset?)
writer to put in timestamps, sequence numbers, etc. 

I am eliminating the merge function and the "-M" option, because "-b"
means percpu files. Also, "stap -b -o foo" will now work and save percpu
data in "foo_N" (where N = cpu number).

Now the real question. I think it would be best to have some basic
format that percpu data is stored in.  I propose having the transport
automatically put the following header on all data:

struct _stp_trace {
        uint32_t sequence;      /* event number */
        uint32_t pdu_len;       /* length of data after this trace */

This allows us to write standard utilities to sequence and extract data
from all percpu files.  I realize this will require modification to
applications which some of you have written to parse percpu files.
However I also think it makes it much easier to use for simple
applications because the system generates the sequence numbers and
lengths automatically.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]