Re: [PATCH v3 tip/core/rcu 3/9] rcu: Add synchronous grace-period waiting for RCU-tasks

[Masami Hiramatsu]

(2014/08/09 2:27), Steven Rostedt wrote:
> On Fri, 8 Aug 2014 18:27:14 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.pt@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/