From: Daniel J Blueman <daniel.blueman@gmail.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org, jgarzik@pobox.com
Subject: Re: PAT status?
Date: Thu, 1 Dec 2005 14:30:01 +0000 [thread overview]
Message-ID: <6278d2220512010630n32174125vbcaac736d169849@mail.gmail.com> (raw)
In-Reply-To: <p73zmnlg5mr.fsf@verdi.suse.de>
On 30 Nov 2005 14:58:20 -0700, Andi Kleen <ak@suse.de> wrote:
> Daniel J Blueman <daniel.blueman@gmail.com> writes:
>
> > IIRC, the kernel (c. 2.6.14) still does nothing to setup the
> > processors' PAT registers to enable write combining in one of the
> > slots - the defaults the BIOS establishes do not cover this. Once this
> > is done, drivers would readily be able to set page flags for a
> > particular PAT slot, and MTRRs can (almost) be safely ignored.
>
> As usual when something hasn't been done yet it's not that easy...
>
> Problem is that they would very likely create very subtle problems
> by creating conflicting mappings with the different cache attributes,
> which leads to cache corruption and other nasty issues.
>
> That is why more infrastructure is needed in the kernel to do this
> properly.
The steps I see that are needed are:
1. on initialisation, the kernel would select one PAT slot to setup
with the (eg) write combining attribute (and other slots for other
attrs)
2. expose an interface to the drivers to set the appropriate bit in a
page (range), based on searching the PAT slots, or using a known one
Intel document [1, section 10] that the uncacheable setting from PAT
or MTRR mechanisms takes precedence over the other mechanism, so the
situation will always be 'safe' (ie w/o cache corruption), and that
write-combining takes precedence over write-through or write-back MTRR
regions.
There are implementations that setup the PAT registers in userland or
in-driver and use the appropriate page flags to refer to the correct
PAT slot.
Daniel
--- [1]
ftp://download.intel.com/design/Pentium4/manuals/25366817.pdf
___
Daniel J Blueman
next prev parent reply other threads:[~2005-12-01 14:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-30 12:04 Daniel J Blueman
2005-11-30 21:58 ` Andi Kleen
2005-12-01 14:30 ` Daniel J Blueman [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-12-08 15:37 Daniel J Blueman
2005-12-09 18:45 ` Dave Jones
2005-11-29 22:22 Jeff Garzik
2005-12-01 20:49 ` Terence Ripperda
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=6278d2220512010630n32174125vbcaac736d169849@mail.gmail.com \
--to=daniel.blueman@gmail.com \
--cc=ak@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®