Re: sort of ... spinlock_softirq()

Juanjo Ciarlante (irriga@impsat1.com.ar)
Fri, 14 Aug 1998 23:45:09 -0300

On Sat, Aug 15, 1998 at 02:18:56AM +0200, Andi Kleen wrote:
> [...]
> >> write_lock_irqsave() is faster than start_bh_atomic(), because
> >> start_bh_atomic calls synchronize_bh currently which can be costly. Also
> >> start_bh_atomic is a global locking algorithm, while write_lock_irqsave
> >> works local which is faster - when irqs are disabled on the current CPU
> >> then other CPUs can still process them. In a start_bh_atomic you block
> >> out all BHs on all CPUs.
> > and what about UP ?
>
> On UP start_bh_atomic is faster.
I see...
So, something like using softirq/UP and hardirq/SMP would the best
approach (?) [with the exception of tiny critical sections]

Some thoughts:
1. I really don't like hardirq/UP ... it's like old cli()/sti() days
2. For hardirq/SMP, "hurt-ness" will depend also on APIC "routing", or no?

Maybe I'm just TOO strong about soft-bh-semantics "matched" by soft-locking
and leaving hardirq semantics for lower levels that require interaction with
hardware.

For example, ipchains (ip_fw.c) uses hardirq locking around lookup loops
that seem quite long given that we are in bh context.
... and still wondering about Alan's tests for 2.1 irq latency.

Regards.

-- 
-- Juanjo       http://juanjox.home.ml.org/




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html