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: [RFC] SystemTap future direction


On Wed, 2010-08-04 at 18:13 +0900, Masami Hiramatsu wrote:
> Mark Wielaard wrote:
> >> This means that if we succeed to merge uprobes into kernel,
> >> SystemTap can't use uprobes itself.
> > 
> > :) So helping push things upstream means not using them yourself.
> > If that happens we can always do what we do now of course, ship our own
> > version. But it would be ideal if we could reuse the upstreamed code of
> > course.
> 
> Hmm, that just makes things worse... Kernel developers migh just think
> us as rogues :(.

Some might already consider us as such :)

> >> Anyway, I think it's the time to discuss how we can get over this
> >> situation and which is the feature direction of SystemTap together.
> >> Since we already has many users, we are responsible to support them.
> > 
> > Yes. I was at GUADEC last week and was happily surprised to meet
> > multiple Gnome hackers who were happy systemtap users. glib and gobject
> > have their own static markers (dtrace compatible) and tapsets now.
> 
> That's a good news. Is that possible perf to support static markers too?

Certainly. They are now also in java, python, mysql, postgresql,
firefox, Ray and Roland are trying to add some to glibc for mutex
monitoring. And I hope gdb will also support them as consumer. So you
can place breakpoints on them. Basically they are just a mapping to a
high-level even name to addresses plus a description of where to find
the arguments. We have had two versions based on including an
allocated .probes elf section in the executable/library. V1 which
required the dwarf location expressions for locating the arguments and
V2 which is includes the locations of the arguments directly (see the
description of the structs in sys/sdt.h). Both are source compatible
with the DTRACE static markers, so people only have to instrument their
executables/libraries once independent of the underlying observation
tool. Roland has proposed a refinement of the way we store the names,
addresses and arguments in a new elf note which doesn't have to be
allocated and which doesn't need relocations (see the "revamp sdt.h"
email on this list from a couple of days ago).

gdb or perf could parse this section (or the new elf note) and select
the addresses to watch for a given event name. It might be good to go
over the proposal from Roland since it includes a "stand alone" parser
that might just be reused as is.

Of course it is harder to reuse the tapsets in other programs based on
these events. But those provide higher-level functionality (mapping
arguments to names, keeping track of arguments/strings constructed,
generating backtraces through jitted code, etc.). For perf just being
able to select and profile the addresses (through uprobes) and record
the arguments is probably a better match for their profiler interfaces
anyway. In GDB you already have access to much more higher level
information anyway, since you will be able to consult the debuginfo and
have the thread under inspection stopped already.

> >> - Port SystemTap on the perf/ftrace but drop embedded-C support.
> >>  This will enhance perf/ftrace to support enough flexible data
> >>  filter/modifier (including fault injection feature). In this case,
> >>  SystemTap scripts will handle the data in user-space (not on-line).
> > 
> > I think the "not on-line" part is a bit of a showstopper. Since that
> > kills the main idea of having powerful scriptable observability. Simple
> > filters are too restrictive IMHO. It might be enough for simple
> > profiling, where you analyze the data off-line afterwards. But that
> > isn't an option for everybody (you need to store/push the data
> > somewhere), and not very efficient some cases.
> 
> The efficiency is the key, and perf and systemtap aim to
> different efficiency. SystemTap focuses on the efficiency of
> transporting data, but perf focuses on the efficiency of
> probing time. What they are trying to is reducing the overhead
> of recording data to buffers, because it is less disturbance for
> the performance of target processes.

Right. It just comes down to priorities of the different goals.
Profiling (with offline analysis) versus scriptable tracing (with some
debugging elements). But making either efficient will help both cases.
We just have to be careful not to trade in one completely for the other,
or we kill useful use cases at probing time.

Cheers,

Mark


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