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]

Re: stptracer-20060828 has released.

Masami Hiramatsu wrote:
Hi Frank,

Frank Ch. Eigler wrote:
Li Guanglei <> 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

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