Re: 2.4 preempt kernel patch

[Jun Sun <jsun@mvista.com>]

On Fri, May 28, 2004 at 01:12:36PM +0900, Atsushi Nemoto wrote:
> Hi.  I'm investigating preempt patch for 2.4 kernel.  (MIPS part of
> preempt-kernel-rml-2.4.26-pre5-1.patch seems a bit old.  I'm looking
> Jun Sun's 030304-b.preempt-mips.patch).
> 
> The patch contains following block (end of
> arch/mips/kernel/irq.c:do_IRQ()):
> 
>  
>  	if (softirq_pending(cpu))
>  		do_softirq();
> +
> +#if defined(CONFIG_PREEMPT)
> +	for(;;) {
> +		preempt_enable_no_resched();
> +		if (preempt_is_disabled() || !need_resched())
> +			break;
> +
> +		db_assert(intr_off());
> +		db_assert(!in_interrupt());
> +
> +		preempt_disable();
> +		__sti();
> +		preempt_schedule();
> +		__cli();
> +	}
> +#endif
> +
>  	return 1;
>  }
>  
> 
> Q1.  What is purpose of this block?  (To decrease latency?  But other
> archs (and 2.6 MIPS kernel) do not have block like this...)
> 

This is to check possible preemption at the end of (possibly nested)
interrupt handling.

All other arches and 2.6 MIPS are doing the same thing in .S file
(something like ret_from_irq path)

> Q2.  If an interrupt happened between __sti() and __cli(), and the
> interrupt handler raise softirq, the softirq handler will not be
> called soon (because do_softirq() immediately return if preempt
> disabled).  So we must check softirq_pending again after this block?
> 

do_softirq() does not (and should not) return when preemtpion is disabled.  
We should be fine here.

Jun