All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Bligh <mbligh@mbligh.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Edward Falk <efalk@google.com>,
	linux-kernel@vger.kernel.org, Michael Davidson <md@google.com>
Subject: Re: [PATCH] Fix x86_64 _spin_lock_irqsave()
Date: Thu, 24 Aug 2006 08:53:39 -0700	[thread overview]
Message-ID: <44EDCB83.2010806@mbligh.org> (raw)
In-Reply-To: <20060823214831.aa687ebe.akpm@osdl.org>

Andrew Morton wrote:
> On Thu, 24 Aug 2006 13:10:09 +1000
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
> 
>>Edward Falk wrote:
>>
>>>Add spin_lock_string_flags and _raw_spin_lock_flags() to 
>>>asm-x86_64/spinlock.h so that _spin_lock_irqsave() has the same 
>>>semantics on x86_64 as it does on i386 and does *not* have interrupts 
>>>disabled while it is waiting for the lock.
>>>
>>>This fix is courtesy of Michael Davidson
>>
>>So, what's the bug? You shouldn't rely on these semantics anyway
>>because you should never expect to wait for a spinlock for so long
>>(and it may be the case that irqs can't be enabled anyway).
>>
>>BTW. you should be cc'ing Andi Kleen (x86+/-64 maintainer) on
>>this type of stuff.
>>
>>No comments on the merits of adding this feature. I suppose parity
>>with i386 is a good thing, though.
>>
> 
> 
> We put this into x86 ages ago and Andi ducked the x86_64 patch at the time.
> 
> I don't recall any reports about the x86 patch (Zwane?) improving or
> worsening anything.  I guess there are some theoretical interrupt latency
> benefits.

Spinlocks are indeed meant to be held for a short time, but irq
disabling is meant to be shorter.

I think the real question is: what is the justification for disabling
interrupts when spinning for a lock? We should never disable interrupts
unless we have to.

M.

  reply	other threads:[~2006-08-24 15:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-24  2:57 [PATCH] Fix x86_64 _spin_lock_irqsave() Edward Falk
2006-08-24  3:10 ` Nick Piggin
2006-08-24  4:48   ` Andrew Morton
2006-08-24 15:53     ` Martin Bligh [this message]
2006-08-26  7:52       ` Keith Owens
2006-08-24  6:45 ` Andi Kleen
2006-08-24 11:04   ` Suleiman Souhlal
2006-08-24 11:13     ` Arjan van de Ven
2006-08-24 11:32     ` Andi Kleen
2006-08-24 12:33       ` Suleiman Souhlal
2006-08-24 13:21         ` Arjan van de Ven
2006-08-24 13:44           ` Suleiman Souhlal
2006-08-25  4:38   ` Andrew Morton
2006-08-25  5:33     ` Nick Piggin
2006-08-25  6:21     ` Andi Kleen

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=44EDCB83.2010806@mbligh.org \
    --to=mbligh@mbligh.org \
    --cc=akpm@osdl.org \
    --cc=efalk@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=md@google.com \
    --cc=nickpiggin@yahoo.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.