stptracer-20060828 has released.

[Li Guanglei]

Masami Hiramatsu wrote:
> Hi Frank,
> 
> Frank Ch. Eigler wrote:
>> Li Guanglei <guanglei@cn.ibm.com> writes:
>>
>>> [...]  So we use _stp_printf() for its fancy printing format in
>>> trade of its slower speed compared with gBTI.  But the interface
>>> like gBTI imposes too much restriction on trace data format and the
>>> number of data items to be traced. Maybe we should find some places
>>> inside _stp_printf() for further performance improvement while still
>>> have the capability to print data freely.
>> To avoid the overhead inherent in dynamic interpretation of formatting
>> strings, we would need to gradually adopt a compiled approach.  The
>> translator is already parsing formatting strings.  It could emit
>> low-level equivalent code to write binary chunks directly.  The
>> runtime would only need to provide buffer-reservation/commit routines.
> 
> It's a good idea.
> I suggest that the stpd should handle each binary chunks correctly.
> 
> In the gBTI approach, each binary data has its length information in
> the head of the entry. So the enhanced merging routine (gbti_merge
> command) can separate those entries correctly even if the routine
> doesn't know the format of the binary data.
> 
> Current systemtap can't merge the temporary files which include
> binary data correctly. I think if each binary chunks has its
> length information, we can merge them correctly.
> 

Actually, LKET will also put the length at the beginning of every 
binary data trunk. So lket-b2a can correctly find the boundary of each 
record.

I simplified _stp_vsnprintf() to make it support only %1b, %2b, %4b, 
%8b format, and it performs almost the same as gBTI. The calls to 
skip_atoi() and some format char checking such as .,+,-,* cost quite 
some time.

So either a compiled approach or a simplified version of 
_stp_vsnprintf() could help the performance improvement. But I have 
some questions about compiled approach. stap will treat all integer 
data as 64-bit, but most binary trace integer data items need only 1 
or 2 bytes. Making them all 8 bytes will waste a lot of space. And 
will it use a fix length for all string items? Some string trace data 
items only have a few chars.

The second question is that it seems to me you need to write 
print/trace statement at script level in the compiled approach. But in 
some situations I will put the print/trace statement in embedded c 
codes to avoid the calls to function__dwarf_tvar_get*. It will become 
a problem if you need to parse a number of data members from a struct. 
One example is the struct scsi_cmnd in scsi trace hooks in LKET. I 
need to retrieve 10 arguments from this struct. In the embedded c 
codes they are only 10 assignments while in stap script they will be 
extended to 10 function calls.

- Guanglei