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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
