Re: Customization of LKET

[fche at redhat dot com (Frank Ch. Eigler)]

Li Guanglei <guanglei@cn.ibm.com> writes:

> I had a talk with Jose last week and we think it would be useful to
> make the user able to append extra data on the trace at script
> level.

It was this kind of flexibility in mind that I proposed the "compiled"
binary tracing alternative in
<http://sourceware.org/ml/systemtap/2006-q1/msg00277.html>.  It was
more recently been mentioned indirectly by Tom in
<http://sourceware.org/ml/systemtap/2006-q2/msg00070.html>.  This
would be a more general solution to flexible & incremental
construction of binary trace records.


> Of course the user could modify the tapsets in tapset/LKET to let
> _lket_trace() log more data. But it's not a convenient way. It's
> obvious that a function like printf() at script level is better, i.e:
> [...]
>     lket_trace_extra("%4b", $numa_node)
> [...]
> #define _lket_trace_extra(fmt, args...)  do {\
>         _stp_printf("%1b%2n%0s"fmt, LKET_PKT_USER, fmt, args);\
> } while(0)

I must say I don't much like this approach.  Is the only point
here to add "LKET_PKT_USER" as a constant byte into the printf?

> I modified systemtap to make it able to support lket_trace_extra at
> script level. [...]

Modify LKET tapset sources at will, but please consider
application-specific changes to the translator proper as possibly
controversial, and allow more time for review.


> [...]
> probe addevent.pagefault
> {
>    lket_trace_extra("%4b%0s", $numa_node, backtrace())
> }
> But there is trouble that MAXSTRINGLEN is defined as 128 so backtrace
> string will be truncated. Simply raising MAXSTRINGLEN will cause a lot
> of waste of memory.

It would be wise to test that assumption.  Remember that the
translator uses a statically allocated array for local values like
string temporaries.  Temporaries for adjacent statements are overlaid.
The overall size of the context structure may be small enough even
with a quadrupled MAXSTRINGLEN for it to work out fine.  Test it and
see.


> Then the user could:
> probe addevent.pagefault
> {
>    lket_backtrace()
>    lket_trace_extra("%4b%0s", $numa_node, backtrace())
> }
> Then he can add as more extra data by lket_trace_extra() as he like
> and the post-processing app(lket-b2a) could recognize the format of
> these extra data.

This whole area seems pretty messy.  Let's think about it for a little
longer before committing to a solution.


- FChE