you talk about 32-bit while i talk about 64-bit. All these costs go up
on 64-bit and you should know that. I measured 44 bytes in the fastpath
and 52 bytes in the slowpath, which gives 96 bytes. (with a distro
.config and likely with a different gcc)
96 bytes _per marker_ sprinkled throughout the kernel. This blows up the
cache footprint of the kernel quite substantially, because it's all
fragmented - even if this is in the 'slowpath'.
so yes, that is the bloat i'm talking about.
dont just compare it to ftrace-sched-switch, compare it to dyn-ftrace
which gives us more than 78,000 trace points in the kernel _here and
today_ at no measurable runtime cost, with a 5 byte NOP per trace point
and _zero_ instruction stream (register scheduling, etc.) intrusion. No
slowpath cost.
and the basic API approach of markers is flawed a well - the coupling to
the kernel is too strong. The correct and long-term maintainable
coupling is via ASCII symbol names, not via any binding built into the
kernel.
With dyn-ftrace (see sched-devel.git/latest) tracing filters can be
installed trivially by users, via function _symbols_, via:
/debugfs/tracing/available_filter_functions
/debugfs/tracing/set_ftrace_filter
wildcards are recognized as well, so if you do:
echo '*lock' > /debugfs/tracing/set_ftrace_filter
all functions that have 'lock' in their name will have their tracepoints
activated transparently from that point on.
even multiple names can be passed in at once:
echo 'schedule wake_up* *acpi*' > /debugfs/tracing/set_ftrace_filter
so it's trivial to use it, very powerful and we've only begun exposing
it towards users. I see no good reason why we'd patch any marker into
the kernel - it's a maintenance cost from that point on.
so yes, my argument is: tens of thousands of lightweight tracepoints in
the kernel here and today, which are configurable via function names,
each of which can be turned on and off individually, and none of which
needs any source code level changes - is an obviously superior approach.
Ingo
--
