[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7E82351C108FA840AB1866AC776AEC460B68CC5F@orsmsx505.amr.corp.intel.com>
Date: Tue, 26 Aug 2008 16:03:31 -0700
From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To: Dave Airlie <airlied@...il.com>
CC: "mingo@...e.hu" <mingo@...e.hu>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"hpa@...or.com" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: RE: [patch 3/4] x86: PAT Update validate_pat_support for intel CPUs
The problem here is both with MTRR entry of UC and even with
default MTRR being UC.
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.
Yes. We can still allow WC mappings only for the RAM
regions and disable PAT WC for all the reserved regions. I will
take a look at that option and see how cleanly we can
enable pat only for set_memory_wc and disable PAT for
ioremap_wc and pci regions.
Thanks,
Venki
>-----Original Message-----
>From: Dave Airlie [mailto:airlied@...il.com]
>Sent: Tuesday, August 26, 2008 12:06 AM
>To: Pallipadi, Venkatesh
>Cc: mingo@...e.hu; tglx@...utronix.de; hpa@...or.com;
>linux-kernel@...r.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 3/4] x86: PAT Update validate_pat_support
>for intel CPUs
>
>On Thu, Aug 21, 2008 at 9:45 AM,
><venkatesh.pallipadi@...el.com> wrote:
>> Pentium III and Core Solo/Duo CPUs have an erratum
>> " Page with PAT set to WC while associated MTRR is UC may
>consolidate to UC "
>> which can result in WC setting in PAT to be ineffective. We
>will disable
>> PAT on such CPUs, so that we can continue to use MTRR WC setting.
>>
>
>IMHO this seems like a bit hammer with which to squash this nut.
>
>I really need PAT support for upcoming GPU stuff, esp where I have
>pages of RAM allocated into a
>GART and I want write-combined access to them. These pages will
>physically me under a write-back MTRR, with a WC PAT entry
>on the PTE mappings.
>
>Can we not just be smarter and fix this when we know we have a UC MTRR
>and a WC PAT mapping inside it?
>
>Dave.
>
>> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
>>
>> ---
>> arch/x86/kernel/cpu/addon_cpuid_features.c | 17 +++++++++++++++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> Index: tip/arch/x86/kernel/cpu/addon_cpuid_features.c
>> ===================================================================
>> --- tip.orig/arch/x86/kernel/cpu/addon_cpuid_features.c
>2008-08-20 14:25:18.000000000 -0700
>> +++ tip/arch/x86/kernel/cpu/addon_cpuid_features.c
>2008-08-20 14:26:39.000000000 -0700
>> @@ -56,9 +56,22 @@ void __cpuinit validate_pat_support(stru
>>
>> switch (c->x86_vendor) {
>> case X86_VENDOR_INTEL:
>> - if (c->x86 == 0xF || (c->x86 == 6 &&
>c->x86_model >= 15))
>> + /*
>> + * There is a known erratum on Pentium III
>and Core Solo
>> + * and Core Duo CPUs.
>> + * " Page with PAT set to WC while
>associated MTRR is UC
>> + * may consolidate to UC "
>> + * Because of this erratum, it is better to
>stick with
>> + * setting WC in MTRR rather than using PAT
>on these CPUs.
>> + *
>> + * Enable PAT WC only on P4, Core 2 or later CPUs.
>> + */
>> + if (c->x86 > 0x6 || (c->x86 == 6 &&
>c->x86_model >= 15))
>> return;
>> - break;
>> +
>> + pat_disable("PAT WC disabled due to known
>CPU erratum.");
>> + return;
>> +
>> case X86_VENDOR_AMD:
>> case X86_VENDOR_CENTAUR:
>> case X86_VENDOR_TRANSMETA:
>>
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists