This is the mail archive of the
mailing list for the systemtap project.
Re: stptracer-20060828 has released.
- From: Li Guanglei <guanglei at cn dot ibm dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com, "Jose R. Santos" <jrs at us dot ibm dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>
- Date: Fri, 01 Sep 2006 11:47:05 +0800
- Subject: Re: stptracer-20060828 has released.
- Organization: IBM CSTL
- References: <44F58A51.email@example.com> <44F69E3C.firstname.lastname@example.org> <email@example.com> <44F7A3EE.firstname.lastname@example.org>
Masami Hiramatsu wrote:
Frank Ch. Eigler wrote:
Li Guanglei <email@example.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
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
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.