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
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:45 EST