> > > 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? > > > > The lock hold time may increase if you are in one ISR > holding a lock > > and some other interrupt occurs. Processor will now call > ISR linked to > > that interrupt (nested interrupts) assuming that priority of newly > > arrived interrupt is more. > > Yes, but isn't that desired? Because the newly arrived > interrupt is of higher priority than the currently executing > ISR and it doesn't need any lock at all, The lock contention is between the process or another instance of same ISR on other processor(say uP1) which are waiting for that same spinlock to be released. They will have to wait till old ISR instance finishes on processor (say uP0). shouldn't the new > ISR experience a lesser interrupt latency (executed before > the current ISR finishes)? > On some real time Oses it is implemented like this, but not on linux I think (CMIIAW). Also in that case you need to calculate how much stack space you need in worst case of interrupt nesting. > > > > > > > > Secondly, is it possible AT ALL to disable a particular > irq at the > > > local CPU? > > > > It depends on the interrupt controller implementation in > h/w. In most > > cases it should be possible. Most of them are quite > programmable where > > you can mask out, disable, enable any interrupt line, set > the priority > > of the interrupt line. > > So we can disable a single interrupt ONLY for the local CPU > (leaving it enabled for other CPUs), right? > Not sure about this. > Thanks, > > Rajat > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
