public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	David Miller <davem@davemloft.net>,
	jeff@garzik.org, paulus@samba.org, torvalds@osdl.org,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: Opinion on ordering of writel vs. stores to RAM
Date: Mon, 11 Sep 2006 19:23:58 +1000	[thread overview]
Message-ID: <1157966638.3879.30.camel@localhost.localdomain> (raw)
In-Reply-To: <1157965372.23085.87.camel@localhost.localdomain>

On Mon, 2006-09-11 at 10:02 +0100, Alan Cox wrote:
> Ar Llu, 2006-09-11 am 10:12 +1000, ysgrifennodd Benjamin Herrenschmidt:
> >  - writel/readl are fully synchronous (minus mmiowb for spinlocks)
> >  - we provide __writel/__readl with some barriers with relaxed ordering
> > between memory and MMIO (though still _precise_ semantics, not arch
> > specific)
> 
> I'd rather they were less precise than your later proposal but that
> reflects the uses I'm considering perhaps.

My latest proposal basically defines the rules that I think are useful
for drivers in practice and leaves anything else undefined on purpose
(which means cannot be relied on).

For example, Rule #1, MMIO vs. MMIO has to be strongly defined. Drivers
have to know they can rely on MMIOs staying in order as issued on a
given CPU (and thus read to flush posted writes works etc...). Rule #2
and #3 cover the common cases of mixing up DMA and MMIO, and rule #4 the
special case of MMIOs leaking out of spinlocks. I purposefully didn't
define rules for MMIO W + memory W, or memory R + MMIO R for example.
That would constraint arch implementations too much and I don't see such
rules being useful in practice.

> >  * Option B:
> > 
> >  - The driver decides at ioremap time wether it wants a fully ordered
> > mapping or not using
> 
> That is expensive because writel/readl end up full of if() while at the
> moment they are often 1 instruction.

Yup. I agree. It also has another drawback, which is to make it
non-obvious when reading driver code wether a given writel() is ordered
or not, and thus wether it needs a barrier or not. So it makes auditing
drivers to find such ordering bugs harder for us. It does make porting
of drivers to relaxed semantics easier tho. In any case, it's not
fundamentally incompatible with my proposal in that we can have
readl/writel do the test thing (thus be either Class 1 or Class 2 as per
defined in my proposal) based on a map-time flag, and have the
__readl/__writel versions always be Class 2 (that is relaxed ordering
and fast). But I'd rather not mix up the problems right now and thus
leave that aside until I'm sure we have an agreement on the semantics
and the __* accessors semantics.

Cheers,
Ben.



  reply	other threads:[~2006-09-11  9:24 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-09  2:03 Opinion on ordering of writel vs. stores to RAM Paul Mackerras
2006-09-09  2:42 ` Linus Torvalds
2006-09-09  3:02   ` Paul Mackerras
2006-09-09  3:54     ` Linus Torvalds
2006-09-09  7:24     ` Benjamin Herrenschmidt
2006-09-09  9:34     ` David Miller
2006-09-09  9:55       ` Jeff Garzik
2006-09-09 10:08         ` David Miller
2006-09-10 17:18           ` Jesse Barnes
2006-09-10 19:35             ` Alan Cox
2006-09-10 21:25               ` Benjamin Herrenschmidt
2006-09-10 22:23                 ` Alan Cox
2006-09-10 22:18                   ` Benjamin Herrenschmidt
2006-09-11 13:19                     ` Jes Sorensen
2006-09-10 23:35                 ` Segher Boessenkool
2006-09-11  0:12                   ` Benjamin Herrenschmidt
2006-09-11  0:34                     ` Jesse Barnes
2006-09-11  1:04                       ` Benjamin Herrenschmidt
2006-09-11  1:13                       ` Segher Boessenkool
2006-09-11  1:35                         ` Benjamin Herrenschmidt
2006-09-11  9:02                     ` Alan Cox
2006-09-11  9:23                       ` Benjamin Herrenschmidt [this message]
2006-09-11  0:25                 ` Jesse Barnes
2006-09-11  0:54                   ` Segher Boessenkool
2006-09-11  1:10                     ` Benjamin Herrenschmidt
2006-09-11  1:48                       ` Segher Boessenkool
2006-09-11  3:53                         ` Benjamin Herrenschmidt
2006-09-11 18:12                     ` Jesse Barnes
2006-09-11  1:00                   ` Benjamin Herrenschmidt
2006-09-11 18:08                     ` Jesse Barnes
2006-09-11 21:32                       ` Benjamin Herrenschmidt
2006-09-10 20:01             ` Segher Boessenkool
2006-09-11 13:21               ` David Miller
2006-09-11 14:17                 ` Segher Boessenkool
2006-09-12  0:32                   ` David Miller
2006-09-12  0:49                     ` Benjamin Herrenschmidt
2006-09-12 16:47                       ` Segher Boessenkool
2006-09-12  0:54                     ` Roland Dreier
2006-09-09 11:16       ` Paul Mackerras
2006-09-09  7:23   ` Benjamin Herrenschmidt
2006-09-09  9:38     ` David Miller
2006-09-09 15:09     ` Alan Cox
2006-09-10 17:19       ` Jesse Barnes
2006-09-10 17:35         ` Michael Buesch
2006-09-10 17:49           ` Linus Torvalds
2006-09-10 18:02             ` Michael Buesch
2006-09-09 15:08   ` Alan Cox
2006-09-09 18:34   ` Auke Kok
2006-09-09 19:10     ` Patrick McFarland
2006-09-09 15:06 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2006-09-11  5:03 Michael Chan
2006-09-11  5:21 ` Benjamin Herrenschmidt
2006-09-12  4:30 Albert Cahalan
2006-09-12  5:30 ` Benjamin Herrenschmidt
2006-09-12  6:04   ` Albert Cahalan
2006-09-12  6:12     ` Benjamin Herrenschmidt
2006-09-12  7:09       ` Albert Cahalan
2006-09-12  7:17         ` Benjamin Herrenschmidt
2006-09-12  7:21           ` Albert Cahalan

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=1157966638.3879.30.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@davemloft.net \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=segher@kernel.crashing.org \
    --cc=torvalds@osdl.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