Ob'plug: with the pending dyn-ftrace function tracer feature we do
something rather close to that already: we have a 5 byte NOP in the
prologue of every function that can be used as a non-destructive 'branch
away' place.
Right now we use that to trace a (regex-ish pattern identified) set of
functions. The regex pattern can be configured runtime via
/debug/tracing/function_filter is not parsed runtime in any fastpath -
it is used to activate/deactivate the tracepoints and patches them from
NOPs into CALLs.
_But_ the same mechanism could perhaps be used to patch the function as
well.
The cost is +5 bytes of NOP for every function in the system, but in
practice we've not been able to measure any actual runtime costs of
these NOPs - neither in micro-benchmarks nor in macro-benchmarks. (the
only real cost here is the +5 bytes of I$ cost - otherwise the NOP will
just be skipped by the decoder.)
the patching of these NOPs is inherently safe because they are inserted
at build time. There's no negative impact to gcc optimizations at all.
We get a nice selection of 75,000 tracepoints in an allmodconfig kernel
- without _any_ source code level impact in the functions.
On the other hand, i'm not opposed to a handful of static markers either
- i think the best model is to have both of these facilities. There are
a couple of 'core events' that are not expressed via function calls, and
even where they are expressed via function calls the function call
layout is not stable while markers are stable across kernel versions.
The notion of "a context-switch happened from task X to task Y" or "task
X woke up task Y" is not going to change anytime soon so i'm not opposed
to exposing that kind of information. And once we accept the static
markers, we might as well make them as cheap as possible.
Ingo
--
