Messages in this thread | | | Date | Wed, 13 Jul 2005 08:41:25 -0700 | From | "Paul E. McKenney" <> | Subject | Re: PREEMPT/PREEMPT_RT question |
| |
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 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/
| |