Need for a new spinlock API?

Need for a new spinlock API?

[Rajat Jain]

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?

I was wondering if it is possible to have a spin lock API that grabs
the lock and disables ONLY the specified irq on the local processor?

Am I missing something here?

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

Re: Need for a new spinlock API?

[Arjan van de Ven]

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

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

Re: Need for a new spinlock API?

[anubhav rakshit]

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

Re: Need for a new spinlock API?

[Arjan van de Ven]

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

Re: Need for a new spinlock API?

[Tzahi Fadida]

On Wednesday 21 March 2007 23:03, Arjan van de Ven wrote:
> 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.

Newbie advice:
Well, looking at LDD3 -> interrupt handling, there are a few functions
void disable_irq(int irq);
void disable_irq_nosync(int irq);
void enable_irq(int irq);

But you cannot use them if you share an irq and your hardware must not 
generate another interrupt while you are handling this one. This is usually 
the case (i think) since many devices have some kind of "handled" register.

-- 
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS:  see at 
http://members.lycos.co.uk/my2nis/spamwarning.html
-
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

Re: Need for a new spinlock API?

[Rajat Jain]

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?

Secondly, is it possible AT ALL to disable a particular irq at the local CPU?

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

RE: Need for a new spinlock API?

[Ajay Singh (ajaysi)]

 

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

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

Ajay.

> 
> Thanks,
> 
> Rajat
> 
> --
> 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
> 
-
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

Re: Need for a new spinlock API?

[Rajat Jain]

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

RE: Need for a new spinlock API?

[Ajay Singh (ajaysi)]

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

The lock contention is between the process or another instance of same
ISR on other processor(say uP1) which are waiting for that same spinlock
to be released. They will have to wait till old ISR instance finishes on
processor (say uP0).

shouldn't the new 
> ISR experience a lesser interrupt latency (executed before 
> the current ISR finishes)?
> 

On some real time Oses it is implemented like this, but not on linux I
think (CMIIAW). Also in that case you need to calculate how much stack
space you need in worst case of interrupt nesting.

> >
> > >
> > > 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?
> 
Not sure about this.

> 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

Re: Need for a new spinlock API?

[Rajat Jain]

> The lock contention is between the process or another instance of same
> ISR on other processor(say uP1) which are waiting for that same spinlock
> to be released. They will have to wait till old ISR instance finishes on
> processor (say uP0).

No, by design there cannot be two instances of your ISR running on two
seperate processes (since the interrupt is disabled on all processors
untill the ISR returns).
-
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

Re: Need for a new spinlock API?

[Arjan van de Ven]

On Thu, 2007-03-22 at 06:42 +0530, Rajat Jain wrote:
> 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?

because if you don't disable all irqs, you get interrupted by others,
and the irq time is added to your hold time.

> 
> Secondly, is it possible AT ALL to disable a particular irq at the local CPU?


not cheaply. You can fidge with apic stuff if you really want to.
It's also horrible in case of shared interrupts :)
-- 
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

Re: Need for a new spinlock API?

[Arjan van de Ven]

On Thu, 2007-03-22 at 11:29 +0530, Rajat Jain wrote:
> > The lock contention is between the process or another instance of same
> > ISR on other processor(say uP1) which are waiting for that same spinlock
> > to be released. They will have to wait till old ISR instance finishes on
> > processor (say uP0).
> 
> No, by design there cannot be two instances of your ISR running on two
> seperate processes (since the interrupt is disabled on all processors
> untill the ISR returns).

but the USERCONTEXT on the other cpu ALSO uses this lock, right?
(Otherwise this entire discussion was moot already, that was your
initial premise)
-- 
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

Re: Need for a new spinlock API?

[Rajat Jain]

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

So on the same lines, if a data structure is accessed in both process
context and in a (single) driver ISR, should a driver use
spin_lock_irqsave() to get the lock in ISR? Or will a simple
spin_lock()  suffice?

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

RE: Need for a new spinlock API?

[GAggarwal]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

Hi Rajat,

I think spin_lock_irqsave() will fulfill the purpose as otherwise it may be
possible that the when a data structure is accessed in process context by
taking spin_lock and an interrupt comes then the ISR will remain in forever
loop waiting for the process context to release the lock result in a
deadlock situation for a uniprocessor system. You can also use
spin_lock_bh() if the data structure is accessed in tasklet (bottom half).
Please CMIIW.

--
Regards,
Gaurav Aggarwal


-----Original Message-----
From: kernelnewbies-bounce@nl.linux.org
[mailto:kernelnewbies-bounce@nl.linux.org]On Behalf Of Rajat Jain
Sent: Wednesday, April 04, 2007 8:57 AM
To: Arjan van de Ven
Cc: kernel mail; newbie
Subject: Re: Need for a new spinlock API?


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

So on the same lines, if a data structure is accessed in both process
context and in a (single) driver ISR, should a driver use
spin_lock_irqsave() to get the lock in ISR? Or will a simple
spin_lock()  suffice?

Thanks,

Rajat


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


The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

[-- Attachment #2: Type: text/html, Size: 4437 bytes --]

Re: Need for a new spinlock API?

[Rajat Jain]

On 4/4/07, GAggarwal@in.safenet-inc.com <GAggarwal@in.safenet-inc.com> wrote:
>
>
> Hi Rajat,
>
> I think spin_lock_irqsave() will fulfill the purpose as otherwise it may be
> possible that the when a data structure is accessed in process context by
> taking spin_lock and an interrupt comes then the ISR will remain in forever
> loop waiting for the process context to release the lock result in a
> deadlock situation for a uniprocessor system.

HI Gaurav,

I meant to use spin_lock_irqsave() in process context and spin_lock()
in IRQ context.

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

RE: Need for a new spinlock API?

[GAggarwal]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Yaa Rajat... I think that will work if datastructure is shared only among
process context thread and one ISR routine.But in case the datastructure is
shared among multiple interrupt context routines say in IRQ handler A and
Tasklet B then you need to use spin_lock_irqsave() routine in IRQ context
too.

--
Gaurav



-----Original Message-----
From: Rajat Jain [mailto:rajat.noida.india@gmail.com]
Sent: Wednesday, April 04, 2007 10:40 AM
To: GAggarwal@in.safenet-inc.com
Cc: kernelnewbies@nl.linux.org; linux-newbie@vger.kernel.org
Subject: Re: Need for a new spinlock API?


On 4/4/07, GAggarwal@in.safenet-inc.com <GAggarwal@in.safenet-inc.com>
wrote:
>
>
> Hi Rajat,
>
> I think spin_lock_irqsave() will fulfill the purpose as otherwise it may
be
> possible that the when a data structure is accessed in process context by
> taking spin_lock and an interrupt comes then the ISR will remain in
forever
> loop waiting for the process context to release the lock result in a
> deadlock situation for a uniprocessor system.

HI Gaurav,

I meant to use spin_lock_irqsave() in process context and spin_lock()
in IRQ context.

Thanks,

Rajat


The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

[-- Attachment #2: Type: text/html, Size: 2512 bytes --]

Re: Need for a new spinlock API?

[anubhav rakshit]

On 4/4/07, Rajat Jain <rajat.noida.india@gmail.com> wrote:
> > > 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.
> > 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...
>
> So on the same lines, if a data structure is accessed in both process
> context and in a (single) driver ISR, should a driver use
> spin_lock_irqsave() to get the lock in ISR? Or will a simple
> spin_lock()  suffice?
a simple spin_lock() should do,as in Linux the ISR's are not
recursive,and you just need protection in a single ISR.

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