From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Roland Dreier <rdreier@cisco.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>,
Trent Piepho <tpiepho@freescale.com>,
Russell King <rmk+lkml@arm.linux.org.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Miller <davem@davemloft.net>,
linux-arch@vger.kernel.org, scottwood@freescale.com,
linuxppc-dev@ozlabs.org, alan@lxorguk.ukuu.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: MMIO and gcc re-ordering issue
Date: Wed, 11 Jun 2008 13:29:35 +1000 [thread overview]
Message-ID: <200806111329.35894.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <200806101219.34995.jbarnes@virtuousgeek.org>
On Wednesday 11 June 2008 05:19, Jesse Barnes wrote:
> On Tuesday, June 10, 2008 12:05 pm Roland Dreier wrote:
> > > me too. That's the whole basis for readX_relaxed() and its cohorts:
> > > we make our weirdest machines (like altix) conform to the x86 norm.
> > > Then where it really kills us we introduce additional semantics to
> > > selected drivers that enable us to recover I/O speed on the abnormal
> > > platforms.
> >
> > Except as I pointed out before, Altix doesn't conform to the norm and
> > many (most?) drivers are missing mmiowb()s that are needed for Altix.
> > Just no one has plugged most devices into an Altix (or haven't stressed
> > the driver in a way that exposes problems of IO ordering between CPUs).
> >
> > It would be a great thing to use the powerpc trick of setting a flag
> > that is tested by spin_unlock()/mutex_unlock() and automatically doing
> > the mmiowb() if needed, and then killing off mmiowb() entirely.
>
> Yeah I think that's what Nick's guidelines would guarantee. And Jes is
> already working on the spin_unlock change you mentioned, so mmiowb() should
> be history soon (in name only, assuming Nick also introduces the I/O
> barriers he talked about for ordering the looser accessors it would still
> be there but would be called io_wmb or something).
Exactly, yes. I guess everybody has had good intentions here, but
as noticed, what is lacking is coordination and documentation.
You mention strong ordering WRT spin_unlock, which suggests that
you would prefer to take option #2 (the current powerpc one): io/io
is ordered and io is contained inside spinlocks, but io/cacheable
in general is not ordered.
I *would* prefer that io/cacheable actually is strongly ordered with
the default accessors. Because if you have that, then the driver
writer never has to care about memory ordering, provided they use
correct locking for SMP issues. Same as x86. With option 2, there
are still windows where you could possibly have issues.
For any high performance drivers that are well maintained (ie. the
ones where slowdown might be noticed), everyone should have a pretty
good handle on memory ordering requirements, so it shouldn't take
long to go through and convert them to relaxed accessors.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jesse Barnes <jbarnes@virtuousgeek.org>, linux-arch@vger.kernel.org
Cc: Roland Dreier <rdreier@cisco.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>,
Trent Piepho <tpiepho@freescale.com>,
Russell King <rmk+lkml@arm.linux.org.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Miller <davem@davemloft.net>,
scottwood@freescale.com, linuxppc-dev@ozlabs.org,
alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: MMIO and gcc re-ordering issue
Date: Wed, 11 Jun 2008 13:29:35 +1000 [thread overview]
Message-ID: <200806111329.35894.nickpiggin@yahoo.com.au> (raw)
Message-ID: <20080611032935.JrYv8qngu1BDzrrPQwsWP68LVjEdvdViPibSagNgGLg@z> (raw)
In-Reply-To: <200806101219.34995.jbarnes@virtuousgeek.org>
On Wednesday 11 June 2008 05:19, Jesse Barnes wrote:
> On Tuesday, June 10, 2008 12:05 pm Roland Dreier wrote:
> > > me too. That's the whole basis for readX_relaxed() and its cohorts:
> > > we make our weirdest machines (like altix) conform to the x86 norm.
> > > Then where it really kills us we introduce additional semantics to
> > > selected drivers that enable us to recover I/O speed on the abnormal
> > > platforms.
> >
> > Except as I pointed out before, Altix doesn't conform to the norm and
> > many (most?) drivers are missing mmiowb()s that are needed for Altix.
> > Just no one has plugged most devices into an Altix (or haven't stressed
> > the driver in a way that exposes problems of IO ordering between CPUs).
> >
> > It would be a great thing to use the powerpc trick of setting a flag
> > that is tested by spin_unlock()/mutex_unlock() and automatically doing
> > the mmiowb() if needed, and then killing off mmiowb() entirely.
>
> Yeah I think that's what Nick's guidelines would guarantee. And Jes is
> already working on the spin_unlock change you mentioned, so mmiowb() should
> be history soon (in name only, assuming Nick also introduces the I/O
> barriers he talked about for ordering the looser accessors it would still
> be there but would be called io_wmb or something).
Exactly, yes. I guess everybody has had good intentions here, but
as noticed, what is lacking is coordination and documentation.
You mention strong ordering WRT spin_unlock, which suggests that
you would prefer to take option #2 (the current powerpc one): io/io
is ordered and io is contained inside spinlocks, but io/cacheable
in general is not ordered.
I *would* prefer that io/cacheable actually is strongly ordered with
the default accessors. Because if you have that, then the driver
writer never has to care about memory ordering, provided they use
correct locking for SMP issues. Same as x86. With option 2, there
are still windows where you could possibly have issues.
For any high performance drivers that are well maintained (ie. the
ones where slowdown might be noticed), everyone should have a pretty
good handle on memory ordering requirements, so it shouldn't take
long to go through and convert them to relaxed accessors.
next prev parent reply other threads:[~2008-06-11 3:29 UTC|newest]
Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4833524C.3040207@freescale.com>
[not found] ` <20080520.153947.84346222.davem@davemloft.net>
[not found] ` <4833542E.3040608@freescale.com>
[not found] ` <20080520.155326.195407196.davem@davemloft.net>
[not found] ` <1211516683.8297.271.camel@pasglop>
[not found] ` <Pine.LNX.4.64.0805221553400.8205@t2.domain.actdsltmp>
2008-05-27 1:33 ` MMIO and gcc re-ordering issue Benjamin Herrenschmidt
2008-05-27 1:40 ` David Miller
2008-05-27 2:15 ` Benjamin Herrenschmidt
2008-05-27 2:28 ` David Miller
2008-05-27 3:39 ` Benjamin Herrenschmidt
2008-05-27 15:35 ` Linus Torvalds
2008-05-27 15:35 ` Linus Torvalds
2008-05-27 16:47 ` Linus Torvalds
2008-05-27 17:31 ` Linus Torvalds
2008-06-02 10:36 ` Ingo Molnar
2008-06-02 21:53 ` Benjamin Herrenschmidt
2008-05-27 21:12 ` Benjamin Herrenschmidt
2008-05-27 18:23 ` Trent Piepho
2008-05-27 18:33 ` Scott Wood
2008-05-27 21:10 ` Benjamin Herrenschmidt
2008-05-27 21:30 ` Linus Torvalds
2008-05-27 21:38 ` Alan Cox
2008-05-27 21:53 ` Matthew Wilcox
2008-05-27 21:46 ` Alan Cox
2008-05-27 22:02 ` Linus Torvalds
2008-05-27 21:59 ` Linus Torvalds
2008-05-27 21:38 ` Benjamin Herrenschmidt
2008-05-27 21:42 ` Matthew Wilcox
2008-05-27 22:17 ` Benjamin Herrenschmidt
2008-05-28 8:36 ` Haavard Skinnemoen
2008-05-29 11:05 ` Pantelis Antoniou
2008-05-30 1:13 ` Benjamin Herrenschmidt
2008-05-30 6:07 ` Haavard Skinnemoen
2008-05-30 7:24 ` Benjamin Herrenschmidt
2008-05-30 8:27 ` Haavard Skinnemoen
2008-05-30 9:22 ` Geert Uytterhoeven
2008-06-02 8:11 ` Haavard Skinnemoen
2008-06-02 15:48 ` Scott Wood
2008-06-03 7:46 ` Haavard Skinnemoen
2008-06-04 15:31 ` Linus Torvalds
2008-05-27 21:55 ` Linus Torvalds
2008-05-27 22:19 ` Benjamin Herrenschmidt
2008-05-29 7:10 ` Arnd Bergmann
2008-05-29 7:10 ` Arnd Bergmann
2008-05-29 10:46 ` Alan Cox
2008-06-02 7:24 ` Russell King
2008-06-02 7:24 ` Russell King
2008-06-03 4:16 ` Nick Piggin
2008-06-03 4:16 ` Nick Piggin
2008-06-03 4:32 ` Benjamin Herrenschmidt
2008-06-03 6:11 ` Nick Piggin
2008-06-03 6:48 ` Benjamin Herrenschmidt
2008-06-03 6:53 ` Paul Mackerras
2008-06-03 7:18 ` Nick Piggin
2008-06-03 7:18 ` Nick Piggin
2008-06-03 14:47 ` Linus Torvalds
2008-06-03 18:47 ` Trent Piepho
2008-06-03 18:55 ` Matthew Wilcox
2008-06-03 19:57 ` Trent Piepho
2008-06-03 21:35 ` Matthew Wilcox
2008-06-03 21:58 ` Trent Piepho
2008-06-04 2:00 ` Nick Piggin
2008-06-03 19:07 ` Linus Torvalds
2008-06-04 2:05 ` Nick Piggin
2008-06-04 2:46 ` Linus Torvalds
2008-06-04 11:47 ` Alan Cox
2008-06-04 11:47 ` Alan Cox
2008-06-10 6:56 ` Nick Piggin
2008-06-10 17:41 ` Jesse Barnes
2008-06-10 18:10 ` James Bottomley
2008-06-10 19:05 ` Roland Dreier
2008-06-10 19:19 ` Jesse Barnes
2008-06-11 3:29 ` Nick Piggin [this message]
2008-06-11 3:29 ` Nick Piggin
2008-06-11 3:40 ` Benjamin Herrenschmidt
2008-06-11 4:06 ` Nick Piggin
2008-06-11 16:07 ` Jesse Barnes
2008-06-11 16:07 ` Jesse Barnes
2008-06-12 11:27 ` Nick Piggin
2008-06-11 4:18 ` Paul Mackerras
2008-06-11 5:00 ` Nick Piggin
2008-06-11 5:13 ` Paul Mackerras
2008-06-11 5:35 ` Nick Piggin
2008-06-11 6:02 ` Nick Piggin
2008-06-12 12:14 ` Paul Mackerras
2008-06-12 13:08 ` Nick Piggin
2008-06-11 14:46 ` Linus Torvalds
2008-06-11 5:20 ` Paul Mackerras
2008-06-11 5:20 ` Paul Mackerras
2008-06-04 2:19 ` Nick Piggin
2008-06-03 19:43 ` Trent Piepho
2008-06-03 21:33 ` Matthew Wilcox
2008-06-03 21:44 ` Trent Piepho
2008-06-04 2:25 ` Nick Piggin
2008-06-04 2:25 ` Nick Piggin
2008-06-04 6:39 ` Trent Piepho
2008-06-03 22:26 ` Benjamin Herrenschmidt
2008-05-27 3:42 ` Arjan van de Ven
2008-05-27 4:08 ` Roland Dreier
2008-05-27 4:20 ` Arjan van de Ven
2008-05-27 7:08 ` Benjamin Herrenschmidt
2008-05-27 7:08 ` Benjamin Herrenschmidt
2008-05-27 15:50 ` Roland Dreier
2008-05-27 16:37 ` James Bottomley
2008-05-27 17:38 ` Roland Dreier
2008-05-27 17:53 ` James Bottomley
2008-05-27 18:07 ` Roland Dreier
2008-05-27 18:17 ` Roland Dreier
2008-05-27 21:23 ` Chris Friesen
2008-05-27 21:23 ` Chris Friesen
2008-05-27 21:29 ` Roland Dreier
2008-05-27 23:04 ` Paul Mackerras
2008-05-27 21:11 ` Benjamin Herrenschmidt
2008-05-27 21:33 ` Roland Dreier
2008-05-27 22:13 ` Benjamin Herrenschmidt
2008-05-27 22:39 ` Roland Dreier
2008-05-29 14:47 ` Jes Sorensen
2008-05-29 15:01 ` James Bottomley
2008-05-30 9:36 ` Jes Sorensen
2008-05-30 17:21 ` Jesse Barnes
2008-05-30 17:21 ` Jesse Barnes
2008-05-31 7:57 ` Jeremy Higdon
2008-05-29 21:40 ` Benjamin Herrenschmidt
2008-05-29 21:48 ` Trent Piepho
2008-05-29 22:05 ` Benjamin Herrenschmidt
2008-05-30 1:53 ` Trent Piepho
2008-05-29 21:53 ` Jesse Barnes
2008-05-29 21:53 ` Jesse Barnes
2008-05-30 9:39 ` Jes Sorensen
2008-05-30 9:48 ` Jes Sorensen
2008-05-31 8:14 ` Pavel Machek
2008-06-02 9:48 ` Jes Sorensen
2008-05-29 22:06 ` Roland Dreier
2008-05-29 22:25 ` Trent Piepho
2008-05-29 22:25 ` Trent Piepho
2008-05-30 3:56 ` Paul Mackerras
2008-05-31 7:52 ` Jeremy Higdon
2008-06-02 9:56 ` Jes Sorensen
2008-06-02 21:02 ` Jeremy Higdon
2008-06-03 4:33 ` Nick Piggin
2008-06-03 8:15 ` Jeremy Higdon
2008-06-03 8:15 ` Jeremy Higdon
2008-06-03 8:19 ` Nick Piggin
2008-06-03 8:45 ` Jeremy Higdon
2008-06-03 16:52 ` Jesse Barnes
2008-06-03 16:52 ` Jesse Barnes
2008-06-05 8:40 ` Jes Sorensen
2008-06-05 8:43 ` Benjamin Herrenschmidt
2008-06-12 15:07 ` Matthew Wilcox
2008-06-13 0:07 ` Benjamin Herrenschmidt
2008-05-31 8:04 ` Pavel Machek
2008-05-27 8:24 ` Alan Cox
2008-05-27 15:28 ` Jonathan Corbet
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=200806111329.35894.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=matthew@wil.cx \
--cc=rdreier@cisco.com \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=scottwood@freescale.com \
--cc=torvalds@linux-foundation.org \
--cc=tpiepho@freescale.com \
/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