Hi - On Tue, Aug 05, 2008 at 03:32:42PM -0700, Roland McGrath wrote: > > 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. > > The overhead (memory + setup/teardown cost) is per-thread X per-tracer. > We'd have to measure what it is in practice. [...]
Right. > The other feature is its simplicity. The "baseline" work to do global > tracing via by-thread is not entirely trivial, as David will attest. Right, though once it's done, it's done ... > For subtrees, there wouldn't any time soon be an option other that > global or by-each-thread. [...] ... and is necessary for this part anyway. > > (An extra chunk of work per clone() may well be cheaper than extra work > > at every system call.) > > I assume what you mean here is for global syscall tracing. There is no > such trade-off. With vanilla utrace, you always do both. With global > tracing, you still always do the latter. The alternative I considered is the nonexistence of global tracing support, thus no utrace_global_flags test in the syscall fast path. > > > 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. [...] > We'd have to discuss concrete scenarios to get entirely clear on this. > [...] Well, it would be desirable to have some facility to block/resume and send signals to threads. It would be desirable for this not to be available only for utrace-probes and not only targeting the currently utrace-hooked thread, but enqueue the command to an arbitrary one. - FChE
