This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: patches to actually use markers?
Hi -
On Fri, Nov 16, 2007 at 03:35:39PM -0500, Mathieu Desnoyers wrote:
> [...]
> > I see. Yes, per-systemcall markers would be welcome by our group, and
> > ones not dependent on TIF_TRACE or whatnot even more so. But were
> > trying not to get too optimistic.
>
> I use per-systemcall markers for the principally useful systemcalls, but
> I also instrument syscall_trace() to get all the other syscalls (new
> ones, etc..).
So then some system calls would get duplicate trace reports, and some
would not get arguments at all? Does not sound ideal.
> I add my own TIF_KERNEL_TRACE, which is a thread flag enabled in
> each and every thread when tracing is active. [...]
Who has responsibility to manage this flag? Would it be reference
counted, so that e.g. two ltt and a third systemtap script all hook
up to these markers, the flag will will stay set? It would be nice to
measure the impact of ordinary, unconditional markers in the
system-call functions.
> > If "we" is a marker callback function that is given the system call
> > number, it can be taught. This is the sort of thing we do currently
> > in systemtap script code based upon kprobes.
>
> Yeah.. but I fear that within the kernel it can become quickly very
> ugly.
It's an inherent tradeoff between a small generic hook versus many
specialized hooks. Look how the audit system deals with decoding
syscalls. It's not THAT bad.
- FChE