Re: [PATCH 1/2] irq_flags_t: intro and core annotations

[David Miller]

From: Jeff Garzik <jeff@xxxxxxxxxx>
Date: Mon, 22 Oct 2007 16:47:16 -0400

> Let me add to the chorus of voices:  I continually see two cases where 
> real bugs crop up:
> 
> 1) hacker uses spin_lock_irq() in incorrect context (where it is not 
> safe to do a blind enable/disable)
> 
> 2) hacker uses spin_lock_irq() correctly, but the surrounding code 
> changes, thus invalidating prior assumptions.
> 
> I would even go so far as to support the drastic measure of deleting 
> spin_lock_irq().
> 
> spin_lock_irqsave() generates fewer bugs, is more future-proof, and by 
> virtue of 'flags' permits architectures a bit more flexibility.

Whilst I agree with you fully on the error-prone'ness argument,
reading the processor interrupt level to fill in the 'flags'
can have non-trivial cost.  I think it's about 9 cycles and
a full pipeline flush on most sparc64 chips for example.

The write to turn off interrupts costs about the same, so you'd
essentially be doubling the execution cost in every case that
you convert as you propose.

I seem to recall that on modern x86 chips the cost of dorking
around with eflags like this is even higher.

What's the relative cost of pushfl/popl/pushl/popfl vs.  cli/sti on
like a core2 duo or a k8?

For 64-bit powerpc's software interrupt disabling scheme it seems
to cost is about equal for both cases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/