From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arjan van de Ven Subject: Re: Need for a new spinlock API? Date: Wed, 21 Mar 2007 22:03:29 +0100 Message-ID: <1174511009.1158.150.camel@laptopd505.fenrus.org> References: <1174462330.1158.113.camel@laptopd505.fenrus.org> <623132dc0703211159n3781bfbdu6ffd43743a6fe377@mail.gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <623132dc0703211159n3781bfbdu6ffd43743a6fe377@mail.gmail.com> Sender: linux-newbie-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii" To: anubhav rakshit Cc: Rajat Jain , kernel mail , newbie On Thu, 2007-03-22 at 00:29 +0530, anubhav rakshit wrote: > On 3/21/07, Arjan van de Ven 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