On Tue, Jul 12, 2005 at 11:54:50PM -0400, Steven Rostedt wrote:
> On Tue, 2005-07-12 at 18:46 -0700, Paul E. McKenney wrote:
>
> > > If you are talking about scheduler_tick, then yes, it is called by the
> > > timer interrupt which is a SA_NODELAY interrupt. If you don't want to
> > > get interrupted by the timer interrupt, then you will need to disable
> > > interrupts for both. Since currently, the timer interrupt is the only
> > > true hard interrupt in the PREEMPT_RT and that may not change.
> >
> > OK, so if I take a spinlock in something invoked from scheduler_tick(),
> > then any other acquisitions of that spinlock must disable hardware
> > interrupts, right?
>
> Yes, otherwise you could have a local CPU deadlock on a SMP machine. And
> I would also say the same is true for any lock that is grabbed by the
> timer interrupt or one of the functions it calls.
OK, I do indeed have critical sections spanning rcu_check_callbacks()
and process-level code. Since rcu_check_callbacks() is called from
account_user_vtime() and update_process_times(), both of which call
scheduler_tick(), looks like I need to disable hardware interrupts.
Looks to me like I need to use _raw_spin_lock() and
_raw_spin_unlock() from within rcu_check_callbacks(), but to instead
use _raw_spin_lock_irqsave() and _raw_spin_lock_irqrestore() outside of
rcu_check_callbacks() for locks acquired within rcu_check_callbacks().
Of course, for fliplock, which is only acquired conditionally from
a rcu_check_callbacks() callee, I can just use spin_trylock() and
spin_unlock(). Though _raw_spin_lock()/_raw_spin_unlock() might be
faster?
No -wonder- I have been seeing hangs in CONFIG_PREEMPT_RT!!! ;-)
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/
