From: Keith Packard <keithp@keithp.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: RE: Mapping PCI BAR through /sys/devices/pci* sets cache-disable andwrite-through
Date: Wed, 16 Apr 2008 22:20:31 -0700 [thread overview]
Message-ID: <1208409631.10327.5.camel@koto.keithp.com> (raw)
In-Reply-To: <924EFEDD5F540B4284297C4DC59F3DEEE5CEA9@orsmsx423.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
On Wed, 2008-04-16 at 15:23 -0700, Pallipadi, Venkatesh wrote:
> Setting flags "_PAGE_PCD | _PAGE_PWT" maps to PAT_3 which is "UC". So,
> the mapping X server will get is UC and if X sets MTRR to WC, it will
> not have any effect on this mapping, which will be still UC. There may
> be apps which depend on this /sys/ interface giving UC mapping always...
Sure, but X wants WC in the biggest way (our measurements show WC being
more than 6 times faster for writes, the operation we do the most of).
Jesse Barnes suggested using the fact that the BAR was prefetchable to
guess that this region should not be mapped UC. I don't know of any
other information available at this API that would help make a better
choice; there are no ioctls on /sys files that we could use to
manipulate the mapping.
> With PAT patches, we now have /sys/devices/pci*resource_wc (in addition
> to resource) for any PREFETCHABLE region. So, X has to change to use
> that new interface to get WC mapping.
Yeah, we'll do that when it becomes available. Would it make sense in
the pre-PAT world to use Jesse's guess?
In any case, we'll continue to use the fact that mprotect is also broken
to get our WC mapping working (using mprotect PROT_NONE followed by
mprotect PROT_READ|PROT_WRITE causes the CD and WT bits to get cleared).
We're fortunate in this case that we've found a bug to exploit that
gives us the desired behaviour.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-04-17 6:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-16 17:40 Mapping PCI BAR through /sys/devices/pci* sets cache-disable and write-through Keith Packard
2008-04-16 22:23 ` Mapping PCI BAR through /sys/devices/pci* sets cache-disable andwrite-through Pallipadi, Venkatesh
2008-04-17 5:20 ` Keith Packard [this message]
2008-04-17 13:14 ` Mapping PCI BAR through /sys/devices/pci* sets cache-disableandwrite-through Pallipadi, Venkatesh
2008-04-17 17:07 ` 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=1208409631.10327.5.camel@koto.keithp.com \
--to=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=venkatesh.pallipadi@intel.com \
/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
Powered by JetHome