On Fri, 2 Apr 2010, David Howells wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > Ahh, yes. In this case, that doesn't likely change anything. The > > save/restore versions of the irq-safe locks shouldn't be appreciably more > > expensive than the non-saving ones. And architectures that really care > > should have done their own per-arch optimized version anyway. > > That depends on the CPU. Some CPUs have quite expensive interrupt disablement > instructions. FRV does for instance; but fortunately, on the FRV, I can use > some of the excessive quantities of conditional registers to pretend that I > disable interrupts, and only actually do so if an interrupt actually happens. I think you're missing the part where we're not _adding_ any irq disables: we're just changing the unconditional irq disable to a save-and-disable (and the unconditional irq enable to a restore). So even if irq's are expensive to disable, the change from spin_lock_irq() to spin_lock_irqsave() won't make that code any more expensive. > > Maybe we should even document that - so that nobody else makes the mistake > > x86-64 did of thinking that the "generic spinlock" version of the rwsem's > > is anything but a hacky and bad fallback case. > > In some cases, it's actually the best way. On a UP machine, for instance, > where they reduce to nothing or where your only atomic instruction is an XCHG > equivalent. Again, you seem to think that we used to have just a plain spin_lock. Not so. We currently have a spin_lock_irq(), and it is NOT a no-op even on UP. It does that irq disable. Anyway, I suspect that even with just an atomic xchg, you can do a better job at doing down_read() than using the generic spin-lock version (likely by busy-looping on a special "we're busy" value). But if you do want to use the generic spin-lock version, I doubt any architecture makes that irqsave version noticeable slower than the unconditional irq version. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
