public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: systemtap@sources.redhat.com
Subject: Re: Discussion at Linux Foundation Japan Symposium
Date: Mon, 12 Jan 2009 19:26:00 -0000	[thread overview]
Message-ID: <20090112192504.GI21793@mit.edu> (raw)
In-Reply-To: <20090111162912.GC18407@redhat.com>

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

  parent reply	other threads:[~2009-01-12 19:26 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-22 18:22 Frank Ch. Eigler
2008-12-22 20:38 ` Theodore Tso
2008-12-22 22:41   ` Frank Ch. Eigler
2008-12-23  0:33     ` Theodore Tso
2008-12-23  0:34       ` Masami Hiramatsu
2008-12-23  0:44         ` Theodore Tso
2008-12-23 21:13           ` Roland McGrath
2008-12-23 22:13           ` Masami Hiramatsu
2008-12-23 14:28       ` Frank Ch. Eigler
2008-12-23 22:21     ` Roland McGrath
2008-12-23 22:33       ` Masami Hiramatsu
2008-12-23 22:44         ` Roland McGrath
2008-12-24  3:40           ` Masami Hiramatsu
2008-12-24  8:48             ` Roland McGrath
2008-12-24 18:14               ` Masami Hiramatsu
2008-12-24 19:26                 ` Roland McGrath
2008-12-24 21:02                 ` Theodore Tso
2008-12-26 18:17                   ` Roland McGrath
2008-12-23 23:27       ` Theodore Tso
2008-12-24  6:11         ` Masami Hiramatsu
2009-01-10  2:48           ` Theodore Tso
2009-01-11 16:29             ` Frank Ch. Eigler
2009-01-12 18:18               ` Masami Hiramatsu
2009-01-12 18:53                 ` Frank Ch. Eigler
2009-01-12 19:29                   ` Masami Hiramatsu
2009-01-12 19:26               ` Theodore Tso [this message]
2009-01-12 20:01                 ` Frank Ch. Eigler
2009-01-12 19:05             ` Jason Baron
2009-01-12 19:52               ` Theodore Tso
2009-01-12 20:32                 ` Frank Ch. Eigler
2009-01-08  9:22         ` Roland McGrath
2009-01-10  1:33           ` Theodore Tso
2008-12-22 23:34   ` Masami Hiramatsu
  -- strict thread matches above, loose matches on Subject: below --
2008-12-18  8:33 Satoshi OSHIMA
2008-12-18  8:59 ` KOSAKI Motohiro
2008-12-18  9:07 ` Jun Koi
2008-12-18  9:21   ` jidong xiao
2008-12-18  9:28     ` Jun Koi
2008-12-18  9:35   ` KOSAKI Motohiro
2008-12-18  9:37     ` Jun Koi
2008-12-18  9:42       ` Jun Koi
2008-12-18  9:46         ` KOSAKI Motohiro
2008-12-18  9:58     ` K.Prasad
2008-12-18 10:02       ` KOSAKI Motohiro
2008-12-18 10:21         ` K.Prasad
2008-12-18 15:52         ` Masami Hiramatsu
2008-12-18 15:41 ` Masami Hiramatsu
2008-12-18 17:11 ` Frank Ch. Eigler
2008-12-19  0:08   ` KOSAKI Motohiro
2008-12-19  0:58     ` Frank Ch. Eigler
2008-12-19  1:39       ` KOSAKI Motohiro
2008-12-19 23:51       ` William Cohen
2008-12-20  1:51         ` Richard J Moore
2008-12-20 14:27         ` Masami Hiramatsu
2008-12-19  0:45   ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090112192504.GI21793@mit.edu \
    --to=tytso@mit.edu \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).