Re: [patch] big IRQ lock removal, 2.5.27-G0

[Ingo Molnar]

On Wed, 24 Jul 2002, Oleg Nesterov wrote:

> I can't understand the preempt_count() check in irq_exit() and
> local_bh_enable(). Did you meant irq_count() instead? I beleive
> preempt_disable() should not disable soft interrupts.

yes, you are right, and i fixed them in -G3.

doh, i *thought* i fixed both places in -G3, but i only fixed irq_exit().  
the local_bh_enable() fix is in -G4:

  http://redhat.com/~mingo/remove-irqlock-patches/remove-irqlock-2.5.27-G4

> In local_bh_enable() it is probably unneeded at all, because nested
> local_bh_disable() is rare (i think), and do_softirq() checks
> in_interrupt().

but still we dont want to call do_softirq() all the time. local_bh_enable
is used in quite performance-sensitive networking code.

> Now suppose preempt_count() & PREEMPT_MASK == 0.
> 
> Then local_bh_enable() has a small preemptible window between
> __local_bh_enable() and do_softirq()->local_irq_save(flags).
> It is only latency problem.

i dont think getting a preemption before softirqs are processed is a big
problem. Such type of preemption comes in form of an interrupt, which 
handles softirqs in irq_exit() anyway, so there's no delay.

> But in irq_exit() case interrupt context may be preempted
> while doing wakeup_softirqd(cpu) after __local_bh_enable()
> in do_softirq().

okay - i've fixed irq_exit() once more in -G4, could you double-check it?

	Ingo