On Mon, Feb 18, 2008 at 01:47:31PM +0100, Jan Kiszka wrote:

K. Prasad wrote:

quoted

Hi Ingo,
	Please accept these patches into the rt tree which convert the
existing RCU tracing mechanism for Preempt RCU and RCU Boost into
markers.
 
These patches are based upon the 2.6.24-rc5-rt1 kernel tree.
 
Along with marker transition, the RCU Tracing infrastructure has also
been modularised to be built as a kernel module, thereby enabling
runtime changes to the RCU Tracing infrastructure.
 
Patch [1/2] - Patch that converts the Preempt RCU tracing in
rcupreempt.c into markers.
 
Patch [1/2] - Patch that converts the Preempt RCU Boost tracing in
rcupreempt-boost.c into markers.
 

I have a technical problem with marker-based RCU tracing: It causes
nasty recursions with latest multi-probe marker patches (sorry, no link
at hand, can be found in latest LTTng, maybe also already in -mm). Those
patches introduce a marker probe trampoline like this:

void marker_probe_cb(const struct marker *mdata, void *call_private,
	const char *fmt, ...)
{
	va_list args;
	char ptype;

	/*
	 * rcu_read_lock does two things : disabling preemption to make sure the
	 * teardown of the callbacks can be done correctly when they are in
	 * modules and they insure RCU read coherency.
	 */
	rcu_read_lock();
	preempt_disable();
	...

Can we do multi-probe with pure preempt_disable/enable protection? I
guess it's fine with classic RCU, but what about preemptible RCU? Any
suggestion appreciated!

If you substitute synchronize_sched() for synchronize_rcu(), this should
work fine.  Of course, this approach would cause RCU tracing to degrade
latencies somewhat in -rt.

If tracing is using call_rcu(), we will need to add a call_sched()
or some such.

						Thanx, Paul

Jan

PS: You will run into this issue if you try to marry latest -rt with
latest LTTng. Straightforward workaround is to comment-out any RCU
trace_mark occurrences.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux