Re: [Ksummit-2008-discuss] DTrace

[fche@redhat.com (Frank Ch. Eigler)]

Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:

>> OK, so you think systemtap should go into the kernel ...
>
> Getting history of systemtap, I'm not sure it will be easily possible :)
> But it is good project for overall Linux advertisement.

> Personally I will not use it, since it is simpler (and very likely
> has smaller performance overhead) to put various kinds of counters
> all over needed places to get required statistics for hot pathes
> like VM and put debug prints in the slow parts.

You may be right for your specific use scenario, or you may be
mistaken.  That is a separate matter from systemtap implementation.


>> [...]
>> ... but now systemtap stay out to userspace?  I don't understand.
>
> You asked how to get needed information. It can be accessed via ptrace,
> so there is no need to have additional kernel module to get it.

You would need to delve deeper into the problem domain then to
understand why dynamic probing is useful to people, and why
nonintrustive user-space probing is useful to people.  Opinions about
"how" to implement something less are not that useful if one didn't
understand/agree-with the "why" (requirements) and "what" (design)
in the first place.


>> > (btw, does systemtap has the same complexity of script writing?
>> 
>> If you point out an example of what you consider a complex dtrace
>> script, I can try to answer that.
>
> Things like  syscall::*read:entry, syscall::*write:entry
> this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0;
> I.e. 'this' and 'self' pointer

"this" in dtrace is shorthand for a thread-specific named data field.
In systemtap, one might use an explicit associative-array expression
"filep[tid()]" to save such values between probes.

FWIW, this script does not strike me as that complex - I've seen much
"worse", both there and in systemtap.  Nor does it strike me as
unnecessarily complex, considering how you'd have to do the same thing
in C code or kprobes or user-space audit or whatever.  YMMV.


- FChE