From: Roland Dreier <rdreier@cisco.com>
To: Andi Kleen <ak@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org, mst@mellanox.co.il,
jackm@mellanox.co.il
Subject: Re: pgprot_writecombine() and PATs on x86
Date: Wed, 25 Apr 2007 11:33:28 -0700 [thread overview]
Message-ID: <adaslaowbgn.fsf@cisco.com> (raw)
In-Reply-To: <200704252019.28017.ak@suse.de> (Andi Kleen's message of "Wed, 25 Apr 2007 20:19:27 +0200")
> > Where do your patches to add an implementation of
> > pgprot_writecombine() using PATs on x86 stand?
>
> It's on my todo list.
Great. Let me know if there's anything I can do to help.
> When it's PCI space you can likely just use MTRRs. PAT is mostly useful
> for applications that do IO with random memory pages
Actually MTRRs seem to be inadequate for a number of reasons. For
example I have a system where /proc/mtrr looks like:
$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg01: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg02: base=0x220000000 (8704MB), size= 256MB: write-back, count=1
reg03: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
And I want to map the second half of the second BAR of this device
with write-combining:
0d:00.0 InfiniBand: Mellanox Technologies Unknown device 634a (rev a0)
Subsystem: Mellanox Technologies Unknown device 634a
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fc400000 (64-bit, non-prefetchable) [size=1M]
Memory at d8000000 (64-bit, prefetchable) [size=8M]
Memory at fc3fe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
So it's not clear that there will be enough MTRRs to handle
everything, or that even if there are enough, that there's a safe way
to update the MTRRs to get from the boot-up config to the one we want.
In this case I guess there is a way but it uses all 8 MTRRs, so adding
a device that also wants write combining won't work.
And definitely trying to set up the MTRRs automatically is going to to
be very fragile. So I think having pgprot_writecombine() implemented
with PATs is really the only sane thing even for this PCI space.
- R.
next prev parent reply other threads:[~2007-04-25 18:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 18:02 pgprot_writecombine() and PATs on x86 Roland Dreier
2007-04-25 18:19 ` Andi Kleen
2007-04-25 18:31 ` Eric W. Biederman
2007-04-25 18:35 ` Roland Dreier
2007-04-25 18:45 ` Eric W. Biederman
2007-04-26 5:43 ` Michael S. Tsirkin
2007-04-26 6:13 ` Eric W. Biederman
2007-04-25 18:33 ` Roland Dreier [this message]
2007-04-25 18:41 ` Dave Jones
2007-04-25 19:10 ` Andi Kleen
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=adaslaowbgn.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=ak@suse.de \
--cc=ebiederm@xmission.com \
--cc=jackm@mellanox.co.il \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@mellanox.co.il \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.