On Thu, 2007-03-22 at 06:42 +0530, Rajat Jain wrote: > Hi Arjan, > > > > > > We often have a case where a driver wants to access its data structure > > > > > in process context as well as in interrupt context (in its ISR). In > > > > > such scenarios, we generally use spin_lock_irqsave() to grab the lock > > > > > as well as disable all the local interrupts. AFAIK, disabling of local > > > > > interrupts is required so as to avoid running your ISR (which needs > > > > > the lock) while process context is holding the lock. However, this > > > > > also disables any other ISRs (which DO NOT need the lock) on the local > > > > > processor. > > > > > > > > > > Isn't this sub-optimal? Shouldn't there be a finer grained locking? > > > > > > > > actually it's optimal. > > > how is it optimal,when all you require is to disable just one particular IRQ? > > > > because if you don't disable all you increase hold times, which > > increases contention. Contention is BAD. > > Do you mean the lock hold time here? How is lock hold time affected by > whether we disable just one or all the irqs? because if you don't disable all irqs, you get interrupted by others, and the irq time is added to your hold time. > > Secondly, is it possible AT ALL to disable a particular irq at the local CPU? not cheaply. You can fidge with apic stuff if you really want to. It's also horrible in case of shared interrupts :) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
