From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: jbarnes@virtuousgeek.org, jeff@garzik.org, paulus@samba.org,
torvalds@osdl.org, linux-kernel@vger.kernel.org,
benh@kernel.crashing.org, akpm@osdl.org
Subject: Re: Opinion on ordering of writel vs. stores to RAM
Date: Mon, 11 Sep 2006 16:17:18 +0200 [thread overview]
Message-ID: <8DA3BCBF-0F19-4CF0-B22E-91E57E7CB033@kernel.crashing.org> (raw)
In-Reply-To: <20060911.062144.74719116.davem@davemloft.net>
>> Why not just keep writel() etc. for *both* purposes; the address
>> cookie
>> it gets as input can distinguish between the required behaviours for
>> different kinds of I/Os; it will have to be setup by the arch-
>> specific
>> __ioremap() or similar.
>
> This doesn't work when the I/O semantics are encoded into the
> instruction, not some virual mapping PTE bits. We'll have to use
> a conditional or whatever in that case, which is silly.
Why is this "silly"? Slowing down I/O accessors by a tiny little
bit isn't expensive, certainly not when compared to the cost of
having to do big-hammer synchronisation all over the place all the
time, like we need to do in the "all busses are strongly ordered
wrt to every other agent in the system" case.
Archs that _do_ implement only one set of ordering rules for every
bus, i.e. use the lowest common denominator on everything, do not
need such a conditional either of course -- only archs that want to
_gain_ performance.
There's plenty of other scenario's where such a conditional is
needed already btw, for example when some host bridges don't implement
PCI memory space as memory-mapped, but via an address+data register
(and yeah you can call such hardware "silly", and I certainly won't
disagree, but...)
Segher
next prev parent reply other threads:[~2006-09-11 14:17 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-09 2:03 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
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 [this message]
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
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=8DA3BCBF-0F19-4CF0-B22E-91E57E7CB033@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=jbarnes@virtuousgeek.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.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
all inboxes | Powered by JetHome®