public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: when spin_lock_irq (as opposed to spin_lock_irqsave) is appropriate?
Date: Sat, 11 Oct 2008 09:18:06 -0700	[thread overview]
Message-ID: <20081011091806.2c8eb2d4@infradead.org> (raw)
In-Reply-To: <200810111929.01927.arvidjaar@mail.ru>

On Sat, 11 Oct 2008 19:29:01 +0400
Andrey Borzenkov <arvidjaar@mail.ru> wrote:

> Logically, one piece of kernel code has no way to know whether another
> piece of kernel code (or may be hard-/firmware) has disabled some
> interrupt line. So it looks like spin_lock_irq should not even exist,
> except may be for very specific cases (where we are sure no other
> piece of kernel code may run concurrently)?
> 
> Sorry for stupid question, I an not actually a HW type of person ...

Hi,

_irq versus _irqsave has nothing to do with hardware, and everything
with the code design.
_irqsave is a little more expensive than _irq, so for really high
performance critical pieces of code, if you know it's ok (more on that
below), it's nicer to use _irq than _irqsave.

Now.. when can you use the _irq versions? The answer is simple to
write, but hard to do in practice:

If you know that when the lock is always taken in this place in a
condition where interrupts are not disabled, you can use _irq. 

This is
because the unlock path for the _irq case will unconditionally enable
interrupts (after all, it didn't save what it was before, so all it can
do is blindly enable it); it's generally not right to enable interrupts
in unlock if they weren't enabled at lock time.
(yes someone could find an exception or two in the kernel, but those
are very very special and carefully crafted places).

Typical cases where interrupts are not enabled when you get called
* You or some other code did a spin_lock_irq/spin_lock_irqsave before,
and this lock just nests inside the outer lock. This can be deliberate
or accidental.
* Your code is used during the suspend/resume paths; these tend to
(partially) run with irqs disabled
* Your code is used in interrupt context; interrupt handlers may run
with interrupts disabled, depending on many conditions.
* During early boot interrupts are off too for some duration

there are more, the list I gave is not exhaustive.

But if you KNOW interrupts will be on (for example, because you just
did a sleeping operation in the same function) you can safely use the
_irq version.


Does this answer your question?



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  parent reply	other threads:[~2008-10-11 16:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-11 15:29 when spin_lock_irq (as opposed to spin_lock_irqsave) is appropriate? Andrey Borzenkov
2008-10-11 15:41 ` Oliver Neukum
2008-10-11 15:55   ` Andrey Borzenkov
2008-10-12  8:08     ` Oliver Neukum
2008-10-11 16:18 ` Arjan van de Ven [this message]
2008-10-12 11:48   ` Andrey Borzenkov
2008-10-12 22:21     ` Arnd Bergmann
2008-10-12 23:12     ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081011091806.2c8eb2d4@infradead.org \
    --to=arjan@infradead.org \
    --cc=arvidjaar@mail.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox