Roland McGrath wrote:
> We've mentioned global tracing. I think it's time now to discuss it
> thoroughly and decide what we do or don't want to do.
...
> 2. Why do we want utrace global tracing?
>From a systemtap point of view, we'd certainly use global tracing.
...
> 3. What would it look like?
>
> Global engines' callbacks all run after all per-task engine callbacks.
> (This could change in future.)
I guess in a "perfect" world callbacks would still be called in the
order they were attached. But, if calling the global callbacks last
makes things easier, I think systemtap could handle it.
> I had originally planned to rule out SYSCALL events for global tracing.
> The reason is that this is not like other event checks where a simple
> flag gets checked cheaply. Instead, it requires setting the low-level
> TIF_SYSCALL_TRACE on a thread, which makes it take a far slower path on
> system call entry and exit, and has a big impact on performance just
> from that alone. Global tracing has to set this individually on every
> thread, and then pay that big overhead across the board.
If we had utrace memory map tracing (I believe it is on your TODO list),
systemtap wouldn't use global (or even per-thread) SYSCALL events as much.
...
> I'd kind of prefer to exclude REAP events for global tracing.
Currently systemtap only uses DEATH events, so I don't have much of an
opinion there.
...
> 4. So, what's the plan?
>
> I need folks who might use global tracing to answer these questions:
>
> a. Do we want it?
Yes. Systemtap currently does "global" tracing now, in a manner similar
to crash-suspend.c. The code looks for global CLONE, EXEC, and DEATH
events, so systemtap knows when threads come and go. Once systemtap
finds a process the user has told us he's interested in, it attaches
some additional per-thread engine(s).
In the future, Frank has mentioned trying to do global memory map
tracing, which would require global syscall tracing (or future global
memory map tracing).
> b. Do we want it right now?
Yes. If you need beta testers, let me know.
> c. What justifies doing it in utrace (vs leaving it purely to
> tracepoints et al), to placate upstream critics?
>
> Please don't say, "That would be nice; your reasons sound good."
> That just does not help at all. The reasons in #2 above are ones I can
> think of, but I'm not arguing for them or for the feature. If you want
> the feature, *you* will be justifying it to the upstream critics. Let's
> here be as skeptical about adding the new complexity, before we decide on
> doing it, as our unsympathetic reviewers will be.
Global tracing would be *really* nice; your reasons sound *great*.
How's that? :-)
Seriously, your reasons a. ("Event vocabulary clearly aligned with
utrace events"), b. ("Coordinated with per-task utrace callbacks"), and
d. ("Kernel already has checks here, so "almost free") apply most
clearly to systemtap. Systemtap doesn't currently change outcomes in a
callback, so reason c. doesn't apply much. Systemtap is interested in
performance impacts and the a./b. advantages seem quite obvious to me.
Avoiding the complexities of manually attaching/detaching to every
thread in the system seems important also.
--
David Smith
[EMAIL PROTECTED]
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
