Re: Need for a new spinlock API?

["anubhav rakshit" <anubhavrocks@gmail.com>]

On 3/21/07, Arjan van de Ven <arjan@infradead.org> 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@nl.linux.org
> 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@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