Messages in this thread | | | Subject | Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108 | From | Michel Dagenais <> | Date | Fri, 15 Sep 2006 11:37:41 -0400 |
| |
> only 5 bytes of NOP are needed by default, so that a kprobe can insert a > call/callq instruction. The easiest way in practice is to insert a > _single_, unconditional function call that is patched out to NOPs upon > its first occurance (doing this is not a performance issue at all). That > way the only cost is the NOP and the function parameter preparation > side-effects. (which might or might not be significant - with register > calling conventions and most parameters being readily available it > should be small.)
Interestingly, while this whole thread is full of diverging views, there is nevertheless considerable common ground.
- Getting a trace output is very useful, whether it is generated from dynamic or static tracepoints. You need some infrastructure (e.g. relayfs + a few things) to get the data out efficiently.
- Some sort of static markers make sense in key locations. Whether they are there "primarily" for dynamic or static tracepoints is mostly irrelevant. Interesting suggestions were made for a syntax clearly identifying their "probe point" status.
>From there we can get onto a constructive debate about the technical details of each of these components.
> note that such a limited, minimally invasive 'data extraction point' > infrastructure is not actually what the LTT patches are doing. It's not > even close, and i think you'll be surprised. Let me quote from the > latest LTT patch (patch-2.6.17-lttng-0.5.108, which is the same version > submitted to lkml - although no specific tracepoints were submitted):
This is a case where it started with inline code but as you take into account SMP and eventuelly multiple traces (e.g. the sysadmin is tracing the system and a user is generating a trace for his processes) it becomes larger and inlining may not be such a good idea any more, to say the least. However, this is relatively easy to change.
It is also worth mentioning that code patching NOPs to minimize the cost of inactive tracepoints was envisioned quite some time ago. Again you might call these "static low overhead placeholders for optimized dynamic tracepoints" or "optimized low overhead static tracepoints"... You need however to be careful when code patching instructions on SMP as it may not be trivial to atomically replace 5 NOPs by a call.
- 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/
| |