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! :) > 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? > > 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. > > 3. Since SPIN_LOCK_UNLOCKED now takes the lock itself as an > argument, what is the best way to initialize per-CPU > locks? An explicit initialization function, or is there > some way that I am missing to make an initializer? Ouch, I just notice that (been using an older version for some time). Ingo, is this to force the initialization of the lists instead of at runtime? -- Steve - 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/
