Hi Mario, Thanks for your inputs. I understood the diabling the irq on the local CPU by spinlock_irqsave function. Can you also explain why should someone use spinlock_irqsave instead of spinlock call. Why someone would want to also disable interrupts while holding a spinlock. One situation i can think of is as using spinlock_irqsave inside an interrupt handler. Is this correct. But i also read that when one interrupt handler is being processed - Linux will mask the same interrupt handler from being called again until the current one has finished processing. that is - Until the processing of interrupt handler is complete. Linux will disable the future interrupts of the same type. In that case why should be disable interrupts by calling ( spinlock_irqsave) and use only spin_lock call alone. Thanks On Tue, Apr 30, 2013 at 2:24 PM, Mario Smarduch <mario.smarduch@xxxxxxxxxx> wrote: > On 4/29/2013 11:21 AM, Ryan wrote: >>> spin_lock_irqsave(lock,flags)/ affects the running >>> > CPU, it does not disable any device IRQ. Device >>> > interrupts may be taken by other CPUs. There is a whole >>> > other set of calls that deal with individual IRQs. >> You mean to say that >> a) Device IRQ can be taken care of some other core of the Same CPU? >> b) If the CPU Load is Less. then only one core will be active. >> In that case - The device irq will be blocked? >> >> > > I don't understand (a), in SMP you may disable IRQs on a CPU > (via *_irqsave()) but other CPUs may continue to receive interrupts. > The CPU load has nothing to do with blocking IRQs (on vanilla kernel) > To disable device IRQ you must disable it at the interrupt controller > level like disable_irq(). > > -- 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
