From: jbarnes@sgi.com (Jesse Barnes)
To: linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Cc: jeremy@sgi.com
Subject: [RFC] Relaxed PIO read vs. DMA write ordering
Date: Wed, 7 Jan 2004 09:58:02 -0800 [thread overview]
Message-ID: <20040107175801.GA4642@sgi.com> (raw)
I've already talked with Grant a little about this, but I'm having
second thoughts about the approach we discussed. PCI-X allows PIO read
responses to 'pass' DMA writes to system memory when the relaxed
ordering bit is set in the PCI-X command word _and_ the transaction has
the relaxed ordering bit set (so called "Relaxed Read Ordering" in
section 11.2 of the PCI-X addendum). This effectively 'unserializes'
PIO vs. DMA transactions so that PIO reads doesn't get stuck behind an
unrelated DMA writes from the same device; something which can
potentially take awhile since cacheline ownership has to be acquired,
etc.
I'd like Linux to support relaxed read ordering in some way since on
large systems having PIO reads stuck behind DMA writes can end up eating
into CPU time and limit IOPS (do I have this right, Jeremy?).
The proposal I gave to Grant added a new readX() variant,
readX_relaxed(), that drivers could use when they don't need strict
ordering semantics (this may actually be the majority of cases, but it's
safer to be strict by default than create a read_ordered and open a
window for data corruption). It might be confusing, however, to add yet
another readX() routine, and there are other ways we might go about it.
One suggestion was to overload the pci_sync_* calls so that they'd
explicitly flush DMA writes to system memory, implying that all reads on
some platforms would use relaxed semantics, but that we'd have to modify
drivers to add in pci_sync_* calls where needed.
Thoughts?
Thanks,
Jesse
next reply other threads:[~2004-01-07 17:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-07 17:58 Jesse Barnes [this message]
2004-01-07 19:02 ` [RFC] Relaxed PIO read vs. DMA write ordering Matthew Wilcox
2004-01-07 22:21 ` Grant Grundler
2004-01-07 23:07 ` Jesse Barnes
2004-01-07 23:27 ` Greg KH
2004-01-07 23:56 ` Jesse Barnes
2004-01-08 0:34 ` Jesse Barnes
2004-01-08 0:08 ` Jeremy Higdon
2004-01-08 10:01 ` Jes Sorensen
2004-01-08 6:38 ` Grant Grundler
2004-01-08 16:23 ` Leonid Grossman
2004-01-08 17:39 ` Jesse Barnes
2004-01-08 17:54 ` Christoph Hellwig
2004-01-08 19:48 ` Leonid Grossman
2004-01-08 17:36 ` Jesse Barnes
2004-01-08 18:44 ` Grant Grundler
2004-01-09 7:13 ` Jeremy Higdon
2004-01-09 19:51 ` Jesse Barnes
2004-01-09 23:15 ` Jesse Barnes
2004-01-09 20:02 ` Grant Grundler
2004-01-11 14:34 ` James Bottomley
2004-01-09 7:39 ` Jochen Friedrich
2004-01-09 20:27 ` Grant Grundler
2004-01-09 22:12 ` Ivan Kokshaysky
2004-01-07 22:58 ` Jesse Barnes
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=20040107175801.GA4642@sgi.com \
--to=jbarnes@sgi.com \
--cc=jeremy@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/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