Re: [PATCH 1/3] tracepoints: Do not use call_rcu_sched() before early_initcall()

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- Original Message -----
> From: "Steven Rostedt" <rostedt@goodmis.org>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: linux-kernel@vger.kernel.org, "Linus Torvalds" <torvalds@linux-foundation.org>, "Ingo Molnar" <mingo@kernel.org>,
> "Andrew Morton" <akpm@linux-foundation.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Paul E. McKenney"
> <paulmck@linux.vnet.ibm.com>
> Sent: Sunday, December 14, 2014 12:21:36 PM
> Subject: Re: [PATCH 1/3] tracepoints: Do not use call_rcu_sched() before early_initcall()
> 
> On Sun, 14 Dec 2014 12:14:57 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > If IRQ setup, or other core pieces of code can use this, then I would
> > agree that rcu should be changed. But until then, I rather not add
> > another conditional to the core RCU code.
> 
> Also, call_rcu*() is called from several hot paths. This location is
> not a hot path, and actually, it is in fact rather slow. That's another
> reason not to add the logic into the RCU code if just adding it to
> tracepoints is sufficient.

Given that your reason for having this RCU-specific logic in tracepoint.c
rather than within call_rcu*() is not slowing down a fast-path, how about
creating a new call_rcu_early() and call_rcu_sched_early() which can be
called in normal operation and at early boot ?

This would allow us to keep the RCU logic within the RCU implementation
rather than strongly coupling it with the tracepoint code.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com