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: Discussion at Linux Foundation Japan Symposium


On Sun, Jan 11, 2009 at 11:29:12AM -0500, Frank Ch. Eigler wrote:
> >    and eventually I suspect markers infrastructure will probably
> >    disappear entirely since tracepoints are perceived as better and
> >    as their replacement.
> 
> (That would probably hurt lttng more than it would systemtap.)

Why do you say that, out of curiosity?  LTTng already has full
tracepoint support, and it is the LTTng maintainer, working in
cooperation with the ftrace developer and others, who has been pushing
tracepoints into mainline.  He's been quite helpful in terms of
working with me so that the ext4 markers can be translated into
tracepoints with no loss of functionality over ext4 markers+systemtap.

> >    Personally, I haven't had a chance to analyze them deeply enough
> >    to know whether this is true, but it's clearly the long-term
> >    direction. [...]
> 
> I hope that before this long-term direction is brought into effect,
> someone does sit down and analyze the issue deeply enough.

What do you believe is wrong with tracepoints?  They are not currently
feature-for-feature identical with markers+Systemtap, today, yes
(which is why I haven't applied LTTng's patch to migrate ext4 markers
to tracepoint, but they are carrying that in the LTTng's kernel git
tree) but aside from needing to write custome probe modules for the
0.01% edge case when I need to filter on something other than a single
device or inode number to reduce the amount of data going to userspace
before I do userspace-side filtering, it looks like it's pretty close.

> You overestimate the amount of duplicated functionality.  For modern
> kernels, systemtap uses the standard in-kernel relay API, with a tiny
> shim.  (If the relay API were ever removed, systemtap would just
> switch to another existing API.  Plain buffering is not rocket
> science.)

Well, if it's not a lot of code, great!  Then it shouldn't be that
hard to prepare the code for upstream submission, assuming you can get
someone like Ingo or Steven to shepherd the code submission.  What is
there does seem to be problematic enough that people need to track
bleeding-edge Systemtap if they want to use bleeding-edge kernels,
which in the long term is a lot of work for all concerned....

      	     	       	    	   	- Ted


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