I did some testing with gcc -Os and -O2 on x86_64 and noticed that -Os
behaves badly in that it does not uses -freorder-blocks. This
optimization is required to have the unlikely branches moved out of the
critical path.
With -O2 :
mov $0,%al
movq %rsi, 1912(%rbx)
movq -96(%rbp), %rdi
incq (%rdi)
testb %al, %al
jne .L1785
4de: b0 00 mov $0x0,%al
4e0: 48 89 b3 78 07 00 00 mov %rsi,0x778(%rbx)
4e7: 48 8b 7d a0 mov 0xffffffffffffffa0(%rbp),%rdi
4eb: 48 ff 07 incq (%rdi)
4ee: 84 c0 test %al,%al
4f0: 0f 85 5f 03 00 00 jne 855 <thread_return+0x2b4>
So, as far as the assembly for the markers in the fast path is
concerned, it adds 10 bytes to the fast path, on x86_64. (I did not
count the %rdi stuff in this since I suppose it's unrelated to markers
and put there by the compiler which reorders instructions)
The bloc which contains the call is much lower at the end of
thread_return.
855: 49 89 f0 mov %rsi,%r8
858: 48 89 d1 mov %rdx,%rcx
85b: 31 f6 xor %esi,%esi
85d: 48 89 da mov %rbx,%rdx
860: 48 c7 c7 00 00 00 00 mov $0x0,%rdi
867: 31 c0 xor %eax,%eax
869: ff 15 00 00 00 00 callq *0(%rip) # 86f <thread_return+0x2ce>
86f: e9 82 fc ff ff jmpq 4f6 <schedule+0x166>
For an added 31 bytes.
Total size added : 41 bytes, 10 of them being in the fast path.
I think the very different compiler options we use change the picture
significantly.
Markers and dyn-ftrace does not fulfill the same purpose, so I don't see
why we should compare them. dyn-ftrace is good at tracing function
entry/exit, so let's keep it. However, it's not designed to extract
variables at specific locations in the kernel code.
Which slowpath cost are you talking about ? When markers are disabled,
their unused function call instructions are placed carefully out of the
kernel running code, along with BUG_ONs and WARN_ONs which already use
some cache lines. You are talking about no measurable runtime cost :
have you tried to measure the runtime cost of disabled markers ? I have
not been able to measure any significant difference with the complete
LTTng marker set compiled into the kernel.
I did something similar with LTTng :
cat /proc/ltt lists the available markers
echo "connect marker_name default dynamic channel_name" > /proc/ltt
Which indicates
- The type of callback to use
- Where the data must be sent (LTTng supports multiple buffers, called
"channels")
So yes, making this easy to use has been done. It's just that the marker
is one building block of the tracing infrastructure, not its entirety.
By the way, I like your tracing filters interface. It seems rather more
polished than my /proc interface. And personnally I don't care wether we
use /proc, debugfs.. as long as there is an interface to userspace.
It's absolutely good to have that into the kernel, but it does not
_replace_ the markers, as I explained above.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
