On 3/21/07, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
On Wed, 2007-03-21 at 09:23 +0530, Rajat Jain wrote: > Hi, > > 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?
It's fastest to delay the interrupts a little and be done with what you want to do under the lock quickly, and THEN take the interrupt. This means the lock hold time is short, which significantly reduces contention on this lock...
Aren't we increasing the latency because of this scheme?
also it's really hard to impossible to get the more complex locking scenarios and dependencies right in this context; it's just so much simpler (and even this simple drivers get it wrong often .. :) -- 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 an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
-- Anubhav Rakshit - 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
