Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:

quoted text
> [...]  SystemTAP, for instance, does it out of tree by keeping a
> separate list of address where kprobes must be installed. It does
> the job on a distribution kernel maintainer perspective (Redhat),
> since they freeze to a particular kernel version and update this
> list every time it breaks, but will always be a source of
> frustration for vanilla kernel users and kernel developers.

This misstates the details.  What systemtap has out-of-tree is a list
of kernel function names (and parameter names), not addresses.  This
list does change somewhat with kernel versions, but we generally keep
up.  We do test with vanilla kernels, and several non-RH distributors
test with their kernels.  It is a problem, but it is manageable.


quoted text
> I think the best way to follow the code flow is to add markup in the
> code itself: it would follow the kernel HEAD and let each subsystem
> maintainer identify the key instrumentation sites of their
> subsystem.

Of course - when and where the dormant overheads are acceptable, and
where the maintainers are willing to commit to a long-term interface
(marker name/arguments).  Systemtap can connect to markers as well as
to kprobes and other event sources: mix & match based on what's
available in your particular kernel and what data/computation you
want.


quoted text
> About extending on ptrace, I am sorry to say that this solution has
> the same downsides as kprobes: it is too slow for high performance
> applications, especially if turned on system-wide. [...]

Roland McGrath's ptrace-replacement (utrace) should help with this.


- FChE
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/