From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] pio barriers
Date: Mon, 10 Dec 2001 23:58:19 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590698805673@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805669@msgid-missing>
>>>>> On Mon, 10 Dec 2001 14:47:40 -0800, Jesse Barnes <jbarnes@sgi.com> said:
Jesse> I noticed that in asm-ia64/system.h there's a comment that reads:
Jesse> /*
Jesse> ...
Jesse> * Note: "mb()" and its variants cannot be used as a fence to order
Jesse> * accesses to memory mapped I/O registers. For that, mf.a needs to
Jesse> * be used. However, we don't want to always use mf.a because (a)
Jesse> * it's (presumably) much slower than mf and (b) mf.a is supported for
Jesse> * sequential memory pages only.
Jesse> */
Jesse> Is there a macro (e.g. piob() or mmiob()) to wrap mf.a or are users
Jesse> expected to call it explicitly when they need it? If there is no
Jesse> macro, I'd like to add one, as I think it will be necessary to
Jesse> properly support our NUMA platform.
The comment is wrong, or at least misleading (I wrote it, so hopefully
nobody is offended... ;-). mf.a is needed for inX/outX emulation, not
really for ordering. Uncached accesses are not re-ordered by the CPU
and mf will do just fine as far as ordering of cached accesses are
concerned.
Platform-acceptance is a tricky business, as it's, well, platform
dependent (note that "mf.a" doesn't really guarantee to do anything).
Can you get away with forcing the proper ordering with a dummy-read?
If so, I suspect that would be preferable as that is the only platform
independent way to do this (as far as I know).
--david
next prev parent reply other threads:[~2001-12-10 23:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-10 22:47 [Linux-ia64] pio barriers Jesse Barnes
2001-12-10 22:57 ` Jack Steiner
2001-12-10 23:00 ` Jesse Barnes
2001-12-10 23:58 ` David Mosberger [this message]
2001-12-11 0:23 ` Jesse Barnes
2001-12-11 0:44 ` David Mosberger
2001-12-11 0:55 ` Jesse Barnes
2001-12-11 5:30 ` David Mosberger
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=marc-linux-ia64-105590698805673@msgid-missing \
--to=davidm@hpl.hp.com \
--cc=linux-ia64@vger.kernel.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