[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: global tracing




David Smith <dsmith redhat com> writes:

> [...]
>> 2. Why do we want utrace global tracing?
>> From a systemtap point of view, we'd certainly use global tracing.

I have a somewhat different take on this.  

This kind of interface would be nice to have in utrace only if it were
significantly cheaper than doing what we do now: potentially attaching
utrace-engines to each thread -- or (in the near future, systemtap
bug# 6445) to subtrees of the process hierarchy.  

(An extra chunk of work per clone() may well be cheaper than extra work
at every system call.)

> Systemtap doesn't currently change outcomes in a callback, so reason
> c. doesn't apply much.  [...]

Actually, this is the main reasons that utrace-level support sounds
interesting to me.  We have had requests for exposing some thread
control primitives to systemtap probe handlers - to block/resume, send
signals, that sort of stuff.  *If* going through utrace (as opposed to
a separate API) would make this smoother and compose better (should
e.g.  there be different systemtap scripts fighting over the threads),
that could be worthwhile.


- FChE


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]