Need for a new spinlock API?

Need for a new spinlock API?

am 21.03.2007 04:53:28 von 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?

am 21.03.2007 08:32:10 von 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?

am 21.03.2007 19:59:09 von anubhav rakshit

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?

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

am 21.03.2007 22:03:29 von Arjan van de Ven

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

Re: Need for a new spinlock API?

am 22.03.2007 00:07:35 von 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 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 (i=
n its
> > > > ISR). In such scenarios, we generally use spin_lock_irqsave() t=
o grab
> > > > the lock as well as disable all the local interrupts. AFAIK,
> > > > disabling of local interrupts is required so as to avoid runnin=
g your
> > > > ISR (which needs the lock) while process context is holding the=
lock.
> > > > However, this also disables any other ISRs (which DO NOT need t=
he
> > > > lock) on the local processor.
> > > >
> > > > Isn't this sub-optimal? Shouldn't there be a finer grained lock=
ing?
> > >
> > > actually it's optimal.
> >
> > how is it optimal,when all you require is to disable just one part=
icular
> > 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=20
generate another interrupt while you are handling this one. This is usu=
ally=20
the case (i think) since many devices have some kind of "handled" regis=
ter.

--=20
Regards,
        Tzahi.
--
Tzahi Fadida
Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info
WARNING TO SPAMMERS: =A0see at=20
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?

am 22.03.2007 02:12:38 von 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?

am 22.03.2007 05:17:20 von 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?

am 22.03.2007 05:33:47 von Rajat Jain

On 3/22/07, Ajay Singh (ajaysi) 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?

am 22.03.2007 05:55:19 von 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?

am 22.03.2007 06:59:10 von 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?

am 22.03.2007 09:50:20 von 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?

am 22.03.2007 09:51:47 von 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?

am 04.04.2007 05:26:42 von 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?

am 04.04.2007 05:50:56 von GAggarwal

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C7766C.733678E6
Content-Type: text/plain;
charset="iso-8859-1"

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.
------_=_NextPart_001_01C7766C.733678E6
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




o-8859-1">
5.5.2658.34">
RE:=20Need=20for=20a=20new=20spinlock=20API?



Hi=20Rajat, >



I=20think=20spin_=
lock_irqsave()=20will=20fulfill=20the=20purpose=20as=20other wise=20it=20ma=
y=20be=20possible=20that=20the=20when=20a=20data=20structure =20is=20access=
ed=20in=20process=20context=20by=20taking=20spin_lock=20and= 20an=20interru=
pt=20comes=20then=20the=20ISR=20will=20remain=20in=20forever =20loop=20wait=
ing=20for=20the=20process=20context=20to=20release=20the=20l ock=20result=20=
in=20a=20deadlock=20situation=20for=20a=20uniprocessor=20sys tem.=20You=20c=
an=20also=20use=20spin_lock_bh()=20if=20the=20data=20structu re=20is=20acce=
ssed=20in=20tasklet=20(bottom=20half).=20Please=20CMIIW.



--

Regards,

Gaurav=20Aggarwa=
l





-----Original=20Message-----

From:=20kernelnewbies-bounce@nl.linu=
x.org

[ ounce@nl.linux.org">mailto:kernelnewbies-bounce@nl.linux.org]On=20Beha=
lf=20Of=20Rajat=20Jain

Sent:=20Wednesday,=20April=2004,=202=
007=208:57=20AM

To:=20Arjan=20van=20de=20Ven

Cc:=20kernel=20mail;=20newbie=


Subject:=20Re:=20Need=20for=20a=20ne=
w=20spinlock=20API?





>=20>=20We=20often=20have=20a=20=
case=20where=20a=20driver=20wants=20to=20access=20its=20data =20structure FONT>

>=20>=20in=20process=20context=
=20as=20well=20as=20in=20interrupt=20context=20(in=20its=20I SR).=20In T>

>=20>=20such=20scenarios,=20we=
=20generally=20use=20spin_lock_irqsave()=20to=20grab=20the=2 0lock

>=20>=20as=20well=20as=20disab=
le=20all=20the=20local=20interrupts.=20AFAIK,=20disabling=20 of=20local NT>

>=20>=20interrupts=20is=20requ=
ired=20so=20as=20to=20avoid=20running=20your=20ISR=20(which= 20needs=


>=20>=20the=20lock)=20while=20=
process=20context=20is=20holding=20the=20lock.=20However,=20 this

>=20>=20also=20disables=20any=20=
other=20ISRs=20(which=20DO=20NOT=20need=20the=20lock)=20on=2 0the=20local FONT>

>=20>=20processor.

>=20>

>=20>=20Isn't=20this=20sub-opt=
imal?=20Shouldn't=20there=20be=20a=20finer=20grained=20locki ng?

>

>=20actually=20it's=20optimal. ONT>

>=20It's=20fastest=20to=20delay=20=
the=20interrupts=20a=20little=20and=20be=20done=20with=20wha t=20you=


>=20want=20to=20do=20under=20the=20=
lock=20quickly,=20and=20THEN=20take=20the=20interrupt.=20Thi s

>=20means=20the=20lock=20hold=20t=
ime=20is=20short,=20which=20significantly=20reduces

>=20contention=20on=20this=20lock=
....



So=20on=20the=20same=20lines,=20if=20=
a=20data=20structure=20is=20accessed=20in=20both=20process

context=20and=20in=20a=20(single)=20=
driver=20ISR,=20should=20a=20driver=20use

spin_lock_irqsave()=20to=20get=20the=
=20lock=20in=20ISR?=20Or=20will=20a=20simple

spin_lock() =20suffice?



Thanks,



Rajat





--

To=20unsubscribe=20from=20this=20lis=
t:=20send=20an=20email=20with

"unsubscribe=20kernelnewbies&qu=
ot;=20to=20ecartis@nl.linux.org

Please=20read=20the=20FAQ=20at=20 HREF=3D"http://kernelnewbies.org/FAQ"=20TARGET=3D"_blank">ht tp://kernelnew=
bies.org/FAQ






The=20information=20contained=20in=20this=20electronic=20mai l=20transmissi=
on=20may=20be=20privileged=20and=20confidential,=20and=20the refore,=20prot=
ected=20from=20disclosure.=20If=20you=20have=20received=20th is=20communica=
tion=20in=20error,=20please=20notify=20us=20immediately=20by =20replying=20=
to=20this=20message=20and=20deleting=20it=20from=20your=20co mputer=20witho=
ut=20copying=20or=20disclosing=20it.



------_=_NextPart_001_01C7766C.733678E6--

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

Re: Need for a new spinlock API?

am 04.04.2007 07:10:25 von Rajat Jain

On 4/4/07, 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?

am 04.04.2007 07:34:44 von GAggarwal

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C7767A.F34279FA
Content-Type: text/plain;
charset="iso-8859-1"

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
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.
------_=_NextPart_001_01C7767A.F34279FA
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




o-8859-1">
5.5.2658.34">
RE:=20Need=20for=20a=20new=20spinlock=20API?



Yaa=20Rajat...=20I=20think=20that=20will=20work=20if=20=
datastructure=20is=20shared=20only=20among=20process=20conte xt=20thread=20=
and=20one=20ISR=20routine.But=20in=20case=20the=20datastruct ure=20is=20sha=
red=20among=20multiple=20interrupt=20context=20routines=20sa y=20in=20IRQ=20=
handler=20A=20and=20Tasklet=20B=20then=20you=20need=20to=20u se=20spin_lock=
_irqsave()=20routine=20in=20IRQ=20context=20too.



--

Gaurav







-----Original=20Message-----

From:=20Rajat=20Jain=20[ da.india@gmail.com">mailto:rajat.noida.india@gmail.com]

Sent:=20Wednesday,=20April=2004,=202007=2010:40=20AM<=
/FONT>

To:=20GAggarwal@in.safenet-inc.com

Cc:=20kernelnewbies@nl.linux.org;=20linux-newbie@vger=
..kernel.org

Subject:=20Re:=20Need=20for=20a=20new=20spinlock=20AP=
I?





On=204/4/07,=20GAggarwal@in.safenet-inc.com=20<GAgg=
arwal@in.safenet-inc.com>=20wrote:

>

>

>=20Hi=20Rajat,

>

>=20I=20think=20spin_lock_irqsave()=20will=20fulfi=
ll=20the=20purpose=20as=20otherwise=20it=20may=20be

>=20possible=20that=20the=20when=20a=20data=20stru=
cture=20is=20accessed=20in=20process=20context=20by

>=20taking=20spin_lock=20and=20an=20interrupt=20co=
mes=20then=20the=20ISR=20will=20remain=20in=20forever

>=20loop=20waiting=20for=20the=20process=20context=
=20to=20release=20the=20lock=20result=20in=20a

>=20deadlock=20situation=20for=20a=20uniprocessor=20=
system.



HI=20Gaurav,



I=20meant=20to=20use=20spin_lock_irqsave()=20in=20proc=
ess=20context=20and=20spin_lock()

in=20IRQ=20context.



Thanks,



Rajat






The=20information=20contained=20in=20this=20electronic=20mai l=20transmissi=
on=20may=20be=20privileged=20and=20confidential,=20and=20the refore,=20prot=
ected=20from=20disclosure.=20If=20you=20have=20received=20th is=20communica=
tion=20in=20error,=20please=20notify=20us=20immediately=20by =20replying=20=
to=20this=20message=20and=20deleting=20it=20from=20your=20co mputer=20witho=
ut=20copying=20or=20disclosing=20it.



------_=_NextPart_001_01C7767A.F34279FA--

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

Re: Need for a new spinlock API?

am 04.04.2007 07:38:10 von anubhav rakshit

On 4/4/07, Rajat Jain 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