From: Brice Goglin <brice@myri.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Dave Airlie <airlied@gmail.com>, "mingo@elte.hu" <mingo@elte.hu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Siddha, Suresh B" <suresh.b.siddha@intel.com>
Subject: Re: [patch 3/4] x86: PAT Update validate_pat_support for intel CPUs
Date: Wed, 27 Aug 2008 07:30:20 +0200 [thread overview]
Message-ID: <48B4E66C.2080806@myri.com> (raw)
In-Reply-To: <7E82351C108FA840AB1866AC776AEC460B68CC5F@orsmsx505.amr.corp.intel.com>
Pallipadi, Venkatesh wrote:
> Default MTRR being UC for all reserved regions and drivers
> wanting WC is very common situation and performance will be
> affected when that ends up being UC access.
> With pat disabled, drivers can set MTRR with WC in this case
> and get the expected performance.
>
Are you saying that drivers are supposed to check if PAT is disabled
before deciding whether they need to setup a MTRR WC? If so, how to do
we check that? Unless we get a way to know whether ioremap_wc() returned
WC or UC, I will always keep the MTRR WC in myri10ge.
Brice
next prev parent reply other threads:[~2008-08-27 5:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-20 23:45 [patch 0/4] PAT Misc updates venkatesh.pallipadi
2008-08-20 23:45 ` [patch 1/4] x86: PAT proper tracking of set_memory_uc and friends venkatesh.pallipadi
2008-08-20 23:45 ` [patch 2/4] x86: PAT Change /dev/mem mmap with O_SYNC to use UC_MINUS venkatesh.pallipadi
2008-08-20 23:45 ` [patch 3/4] x86: PAT Update validate_pat_support for intel CPUs venkatesh.pallipadi
2008-08-26 7:05 ` Dave Airlie
2008-08-26 23:03 ` Pallipadi, Venkatesh
2008-08-27 5:30 ` Brice Goglin [this message]
2008-08-29 22:59 ` Pallipadi, Venkatesh
2008-08-20 23:45 ` [patch 4/4] x86: PAT documentation updates with debug info venkatesh.pallipadi
2008-08-21 11:30 ` [patch 0/4] PAT Misc updates Ingo Molnar
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=48B4E66C.2080806@myri.com \
--to=brice@myri.com \
--cc=airlied@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--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 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.