Re: Using markers w/ preemptible RCU in early code

[Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>]

On Sat, 10 May 2008 17:30:23 -0700
Paul McKenney <Paul.McKenney@us.ibm.com> wrote:

> There might be an easy and harmless fix for early-boot use of 
> synchronize_sched() -- I will look into this.
> 
> As noted above, call_rcu() is not a problem.
> 
> The rcu_barrier*() primitives must never be invoked at early boot
> time. These primitives absolutely must block until all of the
> corresponding flavor of callback has been invoked (and completed),
> but it is not possible to block during early boot.  Perhaps they
> should do a WARN_ON() or BUG_ON() in this case?
> 
> But why are you calling rcu_barrier() during early boot in the first 
> place?

Hi,

Mathieu's code does not call rcu_barrier() explicitely during early
boot. It just happens that I need to use his code (i.e. markers) at that
moment.

My understanding is that we could skip any synchronization primitives
during early code, since there is no SMP and no preemption (and no IRQs
popping around, maybe?). RCU stuff still needs to get registered for
later on, though.

I guess we should write a marker_probe_register() variant for early
code, with no rcu_barrier() and no synchronize_sched() around.

Mathieu, does this sound okay?

(Paul, I removed your alias from the Cc list, so you don't get duplicates.)


Thanks for your input,
		Eduard