Re: scheduler: IRQs disabled over context switches

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Sun, May 23, 2004 at 11:59:01AM -0700, Davide Libenzi wrote:
> On Sun, 23 May 2004, Russell King wrote:
> 
> > The 2.6.6 scheduler disables IRQs across context switches, which is
> > bad news for IRQ latency on ARM - to the point where 16550A FIFO
> > UARTs to overrun.
> > 
> > I'm considering defining prepare_arch_switch & co as follows on ARM,
> > so that we release IRQs over the call to context_switch().
> > 
> > #define prepare_arch_switch(rq,next)		\
> > do {						\
> > 	spin_lock(&(next)->switch_lock);	\
> > 	spin_unlock_irq(&(rq)->lock);		\
> > } while (0)
> > #define finish_arch_switch(rq,prev)		\
> > 	spin_unlock(&(prev)->switch_lock)
> > #define task_running(rq,p)			\
> > 	((rq)->curr == (p) || spin_is_locked(&(p)->switch_lock))
> > 
> > The question is... why are we keeping IRQs disabled over context_switch()
> > in the first case?  Looking at the code, the only thing which is touched
> > outside of the two tasks is rq->prev_mm.  Since runqueues are CPU-
> > specific and we're holding at least one spinlock, I think the above
> > is preempt safe and SMP safe.
> 
> Other archs already do the above.

Not quite - look harder.  They use spin_unlock_irq in finish_arch_switch
rather than prepare_arch_switch.

Ralf Baechle mentioned that he thinks the above on MIPS causes some
rare but weird problems, though he wasn't able to give anything
specific at the time.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core