(2014/08/09 2:27), Steven Rostedt wrote: > On Fri, 8 Aug 2014 18:27:14 +0200 > Peter Zijlstra <pet...@infradead.org> wrote: > >> On Fri, Aug 08, 2014 at 10:58:58AM -0400, Steven Rostedt wrote: >> >>>>> No, they are also used by optimized kprobes. This is why optimized >>>>> kprobes depend on !CONFIG_PREEMPT. [ added Masami to the discussion ]. >>>> >>>> How do those work? Is that one where the INT3 relocates the instruction >>>> stream into an alternative 'text' and that JMPs back into the original >>>> stream at the end? >>> >>> No, it's where we replace the 'int3' with a jump to a trampoline that >>> simulates an INT3. Speeds things up quite a bit. >> >> OK, so the trivial 'fix' for that is to patch the probe site like: >> >> preempt_disable(); INC GS:%__preempt_count >> call trampoline; CALL 0xDEADBEEF >> preempt_enable(); DEC GS:%__preempt_count >> JNZ 1f >> CALL ___preempt_schedule >> 1f: >> >> At which point the preempt_disable/enable() are the read side primitives >> and call_rcu_sched/synchronize_sched are sufficient to release it. >> >> With the per-cpu preempt count stuff we have on x86 that is 4 >> instructions for the preempt_*() stuff -- they're 'big' instructions >> though, since 3 have memops and 2 have a segment prefix. >> >> > > Well, this looks like it may make kprobes a bit more complex, and even > slow down slightly the optimized probe.
This may not only influence the performance, but also reduce the applicability of optprobe too much :( Since the optprobe can replace multiple instructions, it decodes probe site to find out the basic blocks for avoiding the jump instruction to across the border of the basic blocks, which can cause another branch can jump into the jump instruction. So, patching "big" instruction series for the probe site just reduces the possibility of jump optimization. I don't think that is practical. Thank you, > > Also note that if we add call_rcu_tasks(), then perf function tracing > can be called directly instead of being added to the trampoline that > disables and enables preemption before calling it. > > -- Steve > -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/