Linux Newbie help
 help / color / mirror / Atom feed
From: "Rajat Jain" <rajat.noida.india@gmail.com>
To: "Ajay Singh (ajaysi)" <ajaysi@cisco.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	anubhav rakshit <anubhavrocks@gmail.com>,
	kernel mail <kernelnewbies@nl.linux.org>,
	newbie <linux-newbie@vger.kernel.org>
Subject: Re: Need for a new spinlock API?
Date: Thu, 22 Mar 2007 10:03:47 +0530	[thread overview]
Message-ID: <b115cb5f0703212133v4c8fa36cm528866fef3e3e8f9@mail.gmail.com> (raw)
In-Reply-To: <677342AB6AE12D4DB59A9D473F40D74B028E0441@xmb-blr-416.apac.cisco.com>

On 3/22/07, Ajay Singh (ajaysi) <ajaysi@cisco.com> wrote:
>
>
> > -----Original Message-----
> > From: kernelnewbies-bounce@nl.linux.org
> > [mailto:kernelnewbies-bounce@nl.linux.org] On Behalf Of Rajat Jain
> > Sent: Thursday, March 22, 2007 6:43 AM
> > To: Arjan van de Ven
> > Cc: anubhav rakshit; kernel mail; newbie
> > Subject: Re: Need for a new spinlock API?
> >
> > 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, shouldn't the new ISR experience a lesser interrupt
latency (executed before the current ISR finishes)?

>
> >
> > 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?

Thanks,

Rajat
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

  reply	other threads:[~2007-03-22  4:33 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-21  3:53 Need for a new spinlock API? Rajat Jain
2007-03-21  7:32 ` Arjan van de Ven
2007-03-21 18:59   ` anubhav rakshit
2007-03-21 21:03     ` Arjan van de Ven
2007-03-21 23:07       ` Tzahi Fadida
2007-03-22  1:12       ` Rajat Jain
2007-03-22  4:17         ` Ajay Singh (ajaysi)
2007-03-22  4:33           ` Rajat Jain [this message]
2007-03-22  4:55             ` Ajay Singh (ajaysi)
2007-03-22  5:59               ` Rajat Jain
2007-03-22  8:51                 ` Arjan van de Ven
2007-03-22  8:50         ` Arjan van de Ven
2007-04-04  3:26   ` Rajat Jain
2007-04-04  5:38     ` anubhav rakshit
  -- strict thread matches above, loose matches on Subject: below --
2007-04-04  3:50 GAggarwal
2007-04-04  5:10 ` Rajat Jain
2007-04-04  5:34 GAggarwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b115cb5f0703212133v4c8fa36cm528866fef3e3e8f9@mail.gmail.com \
    --to=rajat.noida.india@gmail.com \
    --cc=ajaysi@cisco.com \
    --cc=anubhavrocks@gmail.com \
    --cc=arjan@infradead.org \
    --cc=kernelnewbies@nl.linux.org \
    --cc=linux-newbie@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox