Re: [RFC] RCU and CONFIG_PREEMPT_RT progress, part 3

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Wed, Jul 13, 2005 at 03:06:38PM -0400, Steven Rostedt wrote:
> On Wed, 2005-07-13 at 11:48 -0700, Paul E. McKenney wrote:
> > Hello!
> > 
> > Ported to CONFIG_PREEMPT_RT, and it actually boots!  Running tests,
> 
> Good! :)

Hey, it even passed the touch-test (five kernbenches and an LTP).  Now
to start the torture tests...

> > working thus far.  But thought I would post the patch and get feedback
> > in the meantime, since I am not sure that my approach is correct.
> > The questions:
> > 
> > 1.	Is use of spin_trylock() and spin_unlock() in hardirq code
> > 	(e.g., rcu_check_callbacks() and callees) a Bad Thing?
> > 	Seems to result in boot-time hangs when I try it, and switching
> > 	to _raw_spin_trylock() and _raw_spin_unlock() seems to work
> > 	better.  But I don't see why the other primitives hang --
> > 	after all, you can call wakeup functions in irq context in
> > 	stock kernels...
> 
> I never use _raw_spin_*.  I just declare the lock as a raw_spinlock_t
> and the macro's determine to use them instead.  So I just keep the
> spin_lock in the code. Or do you mean that you get problems using the
> spin_locks when the code is already defined as raw_spinlock_t?

Wasn't aware of this possibility, will try it.  Thanks for the tip!

> > 2.	Is _raw_spin_lock_irqsave() intended for general use?  Its
> > 	API differs from that of spin_lock_irqsave(), so am wondering
> > 	if it is internal-use-only or something.  I currently
> > 	use it from process context to acquire locks shared with
> > 	rcu_check_callbacks().
> 
> I would assume not, but Ingo would be better at answering this.

Seems to work, FWIW.  ;-)

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