This is the mail archive of the systemtap@sourceware.org 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: Implementing a generic binary trace interface.


Martin Hunt wrote:
> On Thu, 2006-01-26 at 11:46 -0600, Jose R. Santos wrote:
> 
> 
>>This sound like a good idea, but I wonder how it will perform compared 
>>to gBTI.  For the purposes of trace, I think the best implementation is 
>>the one with the best performance and smallest impact on the system.  If 
>>we can get something like this to perform as good or better that gBTI 
>>the is also a good candidate.  
> 
> 
> The difference between the two is minor. gBTI passes in an integer that
> is the number of 64-bit ints to log. 
> 
> _stp_binary_write(2, (int64_t)current->pid, (int64_t)current);
> 
> my proposal passes is a simple format string
> 
> _stp_trace("%2b%4b", current->pid, current)
> 
> There is a very small additional overhead involved in parsing that
> format string. That should be offset by not always having to write 64-
> bit binary values.
> 
> gBTI also defines a packet format to be used over the transport.
> [seq-id][\0][num][arg1][arg2]....[arg(num-1)]
> 
> I am not doing that. Whatever program is processing the output just
> needs to understand the format you write.

Why Masami add [num] field and use 64bit fixed length is
to understand the length of each data.

Tapsets usually write some kind of data structures consist
of different format.

You can see how lkst_gbti.stp find the format type.

function lkst_trace(etype:long, arg1:long, arg2:long, arg3:long, arg4:long) %{
	int64_t tsc;
	rdtscll(tsc);
	_stp_binary_write (6,
			  THIS->etype << 40 |
			  (int64_t)smp_processor_id() << 32 | current->pid,
			  tsc, THIS->etype, THIS->arg1, THIS->arg2,
			  THIS->arg3, THIS->arg4);
%}

lkst_trace() have etype argument. This indicates the format.

Generally, we need to include length and format type information
in the header of binary data packet.

gBTI provides length information but dones not provide format
type information. So user who writes tapset should/must include
format information as a contents.

On the other hand, your proposal requires that user must calculate
and inlude length and format information. And it is much flexible
comparing to gBTI.

I think we should have both.


------------------
Satoshi Oshima
Hitachi Computer Product (America) Inc.


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