Re: A spinlock_irqsave question

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
<[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs