Re: Need for a new spinlock API?

[Arjan van de Ven <arjan@infradead.org>]

On Thu, 2007-03-22 at 00:29 +0530, anubhav rakshit wrote:
> 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?

because if you don't disable all you increase hold times, which
increases contention. Contention is BAD.
> 
> > 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?

very very tiny amounts; since typically lock hold times are really short


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