Re: [PATCH 4/4 RFC] RCU: synchronize_sched() without migration

On Wed, Aug 08, 2007 at 12:44:30AM +0530, Dipankar Sarma wrote:

On Tue, Aug 07, 2007 at 11:52:26AM -0700, Paul E. McKenney wrote:

quoted

The combination of CPU hotplug and PREEMPT_RCU has resulted in deadlocks
due to the migration-based implementation of synchronize_sched() in -rt.
This experimental patch maps synchronize_sched() back onto Classic RCU,
eliminating the migration, thus hopefully also eliminating the deadlocks.
It is not clear that this is a good long-term approach, but it will at
least permit people doing CPU hotplug in -rt kernels additional wiggle
room in their design and implementation.

The basic approach is to cause the -rt kernel to incorporate rcuclassic.c
as well as rcupreempt.c, but to #ifdef out the conflicting portions of
rcuclassic.c so that only the code needed to implement synchronize_sched()
remains in a PREEMPT_RT build.  Invocations of grace-period detection
from the scheduling-clock interrupt go to rcuclassic.c, which then invokes
the corresponding functions in rcupreempt.c (with _rt suffix added to
keep the linker happy).  Also applies the RCU_SOFTIRQ to classic RCU.
The bulk of this patch just moves code around.

If this patch does turn out to be the right approach, the #ifdefs in
kernel/rcuclassic.c might be dealt with.  ;-)

I think the right thing to do would be to fix cpu hotplug to
use a simple reference count, as the latest patches Gautham
is working on. That simplifies the implementation from the
earlier version with a per-cpu reference counter with RCU.
No freezer, no lock.

Works for me -- I will just keep this patch for testing of the
CPU hotplug stuff I am adding to preemptible RCU.  Speaking of which,
any advise on good testing methods for CPU hotplug would be greatly
appreciated!!!

						Thanx, Paul