From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org, Jesse Barnes <jesse.barnes@intel.com>,
linuxppc-dev@ozlabs.org
Subject: Re: wmb vs mmiowb
Date: Thu, 23 Aug 2007 06:20:38 +0200 [thread overview]
Message-ID: <20070823042038.GI18788@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.0.999.0708221953360.30176@woody.linux-foundation.org>
On Wed, Aug 22, 2007 at 07:57:56PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > > Irix actually had an io_unlock() routine that did this
> > > implicitly, but iirc that was shot down for Linux...
> >
> > Why was it shot down? Seems like a pretty good idea to me ;)
>
> It's horrible. We'd need it for *every* single spinlock type. We have lots
> of them.
>
> So the choice is between:
>
> - sane:
>
> mmiowb()
>
> followed by any of the existing "spin_unlock()" variants (plain,
> _irq(), _bh(), _irqrestore())
>
> - insane: multiply our current set of unlock primitives by two, by making
> "io" versions for them all:
>
> spin_unlock_io[_irq|_irqrestore|_bh]()
>
> but there's actually an EVEN WORSE problem with the stupid Irix approach,
> namely that it requires that the unlocker be aware of the exact details of
> what happens inside the lock. If the locking is done at an outer layer,
> that's not at all obvious!
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock. The disadvantage is that the caller may not
know if the inner layer performed ios that require the mmiowb, but
the advantage of waiting until unlock is that the wait is deferred
for as long as possible, and will hopefully be a shorter one when
performed later.
next prev parent reply other threads:[~2007-08-23 4:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-22 4:57 wmb vs mmiowb Nick Piggin
2007-08-22 18:07 ` Linus Torvalds
2007-08-22 19:02 ` Jesse Barnes
2007-08-23 2:20 ` Nick Piggin
2007-08-23 2:57 ` Linus Torvalds
2007-08-23 3:54 ` Nick Piggin
2007-08-23 16:14 ` Linus Torvalds
2007-08-23 4:20 ` Nick Piggin [this message]
2007-08-23 16:16 ` Linus Torvalds
2007-08-23 16:27 ` Benjamin Herrenschmidt
2007-08-24 3:09 ` Nick Piggin
2007-08-28 20:56 ` Brent Casavant
2007-08-29 0:59 ` Nick Piggin
2007-08-29 18:53 ` Brent Casavant
2007-08-30 3:36 ` Nick Piggin
2007-08-30 19:42 ` Brent Casavant
2007-09-03 20:48 ` Nick Piggin
2007-08-24 2:59 ` Nick Piggin
2007-08-23 17:02 ` Jesse Barnes
2007-08-23 1:59 ` Nick Piggin
2007-08-23 7:27 ` Benjamin Herrenschmidt
2007-08-23 16:56 ` Jesse Barnes
2007-08-24 3:12 ` Nick Piggin
2007-08-28 21:21 ` Brent Casavant
2007-08-28 23:01 ` Peter Chubb
2007-08-23 7:25 ` Benjamin Herrenschmidt
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=20070823042038.GI18788@wotan.suse.de \
--to=npiggin@suse.de \
--cc=jesse.barnes@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).