>From 3385e0ae9596dc0538023166c800b0f8d2accce2 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <[email protected]>
Date: Sun, 11 Oct 2009 08:40:15 -0700
Subject: [PATCH] x86: Relegate CONFIG_PAT to EMBEDDED
PAT support (which got added to CPUs over 10 years ago) is no longer
really optional in that more and more things are depending on PAT
just working, including newer versions of X. Having this as a regular
config option just no longer makes sense.
This patch relegates CONFIG_PAT to the EMBEDDED category, in the hope
to eventually completely retire it.
Signed-off-by: Arjan van de Ven <[email protected]>
---
arch/x86/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4427956..16d9d40 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1393,7 +1393,8 @@ config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
config X86_PAT
bool
- prompt "x86 PAT support"
+ default y
+ prompt "x86 PAT support" if EMBEDDED
depends on MTRR
---help---
Use PAT attributes to setup page level cache control.
--
1.6.2.5
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
Makes sense, but given that X86_PAT depends on MTRR
config X86_PAT
bool
- prompt "x86 PAT support"
+ default y
+ prompt "x86 PAT support" if EMBEDDED
depends on MTRR
should we give the same treatment to the MTRR option too? (As far as I
can tell, MTRR defaults to n in the current Kconfig too)
- R.
On 10/11/2009 11:04 AM, Roland Dreier wrote:
> Makes sense, but given that X86_PAT depends on MTRR
>
> config X86_PAT
> bool
> - prompt "x86 PAT support"
> + default y
> + prompt "x86 PAT support" if EMBEDDED
> depends on MTRR
>
> should we give the same treatment to the MTRR option too? (As far as I
> can tell, MTRR defaults to n in the current Kconfig too)
I think so, you'd have to be fairly insane to want to disable MTRR support..
On Sun, 11 Oct 2009 10:04:10 -0700
Roland Dreier <[email protected]> wrote:
> Makes sense, but given that X86_PAT depends on MTRR
>
> config X86_PAT
> bool
> - prompt "x86 PAT support"
> + default y
> + prompt "x86 PAT support" if EMBEDDED
> depends on MTRR
>
> should we give the same treatment to the MTRR option too? (As far as
> I can tell, MTRR defaults to n in the current Kconfig too)
>
good point
>From db3a4eb2b16907c0651ed5d4bcdfbd395a0a7ad4 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <[email protected]>
Date: Sun, 11 Oct 2009 08:40:15 -0700
Subject: [PATCH] x86: Relegate CONFIG_X86_PAT and CONFIG_MTRR to EMBEDDED
MTRR and PAT support (which got added to CPUs over 10 years ago) are no
longer really optional in that more and more things are depending on PAT
just working, including various drivers and newer versions of X. (to not
even speak of MTRR)
Having this as a regular config option just no longer makes sense.
This patch relegates CONFIG_X86_PAT to the EMBEDDED category, in the hope to
eventually completely retire it.
Signed-off-by: Arjan van de Ven <[email protected]>
---
arch/x86/Kconfig | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4427956..2fbc3c6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1327,7 +1327,9 @@ config MATH_EMULATION
kernel, it won't hurt.
config MTRR
- bool "MTRR (Memory Type Range Register) support"
+ bool
+ default y
+ prompt "MTRR (Memory Type Range Register) support" if EMBEDDED
---help---
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
@@ -1393,7 +1395,8 @@ config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
config X86_PAT
bool
- prompt "x86 PAT support"
+ default y
+ prompt "x86 PAT support" if EMBEDDED
depends on MTRR
---help---
Use PAT attributes to setup page level cache control.
--
1.6.2.5
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sun, 11 Oct 2009, Arjan van de Ven wrote:
> MTRR and PAT support (which got added to CPUs over 10 years ago) are no
> longer really optional in that more and more things are depending on PAT
> just working, including various drivers and newer versions of X. (to not
> even speak of MTRR)
Please take a look at early_init_intel() in arch/x86/kernel/cpu/intel.c.
it disables PAT for what must amount to more than a *million* of
machines. It certainly includes all Centrino laptops, for example(!).
FYI, these computers will be with us for at least 10 years, still. I
still have users of Mobile Pentium II reporting bugs on thinkpad-acpi,
and I know of a *huge* number of active Pentium II and Pentium III
desktops in Brazil. My 5-year-old ThinkPad T43 (Centrino, Pentium M)
cheerfully reports "PAT not supported by CPU" at boot if I decide to
waste memory by enabling CONFIG_X86_PAT.
So, unless that blacklist can be drastically reduced somehow, can we
*please* fix anything that depends on PAT "just working"? Because as
far as the kernel is concerned right now, way too many machines can't
even dream of using PAT.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Commit-ID: c03cb3149daed3e411657e3212d05ae27cf1a874
Gitweb: http://git.kernel.org/tip/c03cb3149daed3e411657e3212d05ae27cf1a874
Author: Arjan van de Ven <[email protected]>
AuthorDate: Sun, 11 Oct 2009 10:33:02 -0700
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 12 Oct 2009 13:06:57 +0200
x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
MTRR and PAT support (which got added to CPUs over 10 years ago)
are no longer really optional in that more and more things are
depending on PAT just working, including various drivers and newer
versions of X. (to not even speak of MTRR)
Having this as a regular config option just no longer makes sense.
This patch relegates CONFIG_X86_PAT to the EMBEDDED category so
ultra-embedded can still disable it if they really need to.
Also-Suggested-by: Roland Dreier <[email protected]>
Signed-off-by: Arjan van de Ven <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Henrique de Moraes Holschuh <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/Kconfig | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c876bac..a67363b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1321,7 +1321,9 @@ config MATH_EMULATION
kernel, it won't hurt.
config MTRR
- bool "MTRR (Memory Type Range Register) support"
+ bool
+ default y
+ prompt "MTRR (Memory Type Range Register) support" if EMBEDDED
---help---
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
@@ -1387,7 +1389,8 @@ config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT
config X86_PAT
bool
- prompt "x86 PAT support"
+ default y
+ prompt "x86 PAT support" if EMBEDDED
depends on MTRR
---help---
Use PAT attributes to setup page level cache control.
On 10/12/2009 04:10 AM, tip-bot for Arjan van de Ven wrote:
> Commit-ID: c03cb3149daed3e411657e3212d05ae27cf1a874
> Gitweb: http://git.kernel.org/tip/c03cb3149daed3e411657e3212d05ae27cf1a874
> Author: Arjan van de Ven <[email protected]>
> AuthorDate: Sun, 11 Oct 2009 10:33:02 -0700
> Committer: Ingo Molnar <[email protected]>
> CommitDate: Mon, 12 Oct 2009 13:06:57 +0200
>
> x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
>
> MTRR and PAT support (which got added to CPUs over 10 years ago)
> are no longer really optional in that more and more things are
> depending on PAT just working, including various drivers and newer
> versions of X. (to not even speak of MTRR)
>
> Having this as a regular config option just no longer makes sense.
>
> This patch relegates CONFIG_X86_PAT to the EMBEDDED category so
> ultra-embedded can still disable it if they really need to.
>
Should we combine this with removing the whitelist (which is largely
vestigial at this point) and replace it with a blacklist (possibly
empty)? I still haven't seen any evidence that there are any CPUs which
have problems, and PAT support go back all the way to Pentium III -- and
page table attributes can be used all the way back to 386, it just
excludes the WC type.
-hpa
H. Peter Anvin wrote:
> On 10/12/2009 04:10 AM, tip-bot for Arjan van de Ven wrote:
>> Commit-ID: c03cb3149daed3e411657e3212d05ae27cf1a874
>> Gitweb: http://git.kernel.org/tip/c03cb3149daed3e411657e3212d05ae27cf1a874
>> Author: Arjan van de Ven <[email protected]>
>> AuthorDate: Sun, 11 Oct 2009 10:33:02 -0700
>> Committer: Ingo Molnar <[email protected]>
>> CommitDate: Mon, 12 Oct 2009 13:06:57 +0200
>>
>> x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
>>
>> MTRR and PAT support (which got added to CPUs over 10 years ago)
>> are no longer really optional in that more and more things are
>> depending on PAT just working, including various drivers and newer
>> versions of X. (to not even speak of MTRR)
>>
>> Having this as a regular config option just no longer makes sense.
>>
>> This patch relegates CONFIG_X86_PAT to the EMBEDDED category so
>> ultra-embedded can still disable it if they really need to.
>>
>
> Should we combine this with removing the whitelist (which is largely
> vestigial at this point) and replace it with a blacklist (possibly
> empty)? I still haven't seen any evidence that there are any CPUs which
> have problems, and PAT support go back all the way to Pentium III -- and
> page table attributes can be used all the way back to 386, it just
> excludes the WC type.
I would be in favor of that; other operating systems have been using pat everywhere
since the pII days anyway.
* Arjan van de Ven <[email protected]> wrote:
> H. Peter Anvin wrote:
>> On 10/12/2009 04:10 AM, tip-bot for Arjan van de Ven wrote:
>>> Commit-ID: c03cb3149daed3e411657e3212d05ae27cf1a874
>>> Gitweb: http://git.kernel.org/tip/c03cb3149daed3e411657e3212d05ae27cf1a874
>>> Author: Arjan van de Ven <[email protected]>
>>> AuthorDate: Sun, 11 Oct 2009 10:33:02 -0700
>>> Committer: Ingo Molnar <[email protected]>
>>> CommitDate: Mon, 12 Oct 2009 13:06:57 +0200
>>>
>>> x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
>>>
>>> MTRR and PAT support (which got added to CPUs over 10 years ago)
>>> are no longer really optional in that more and more things are
>>> depending on PAT just working, including various drivers and newer
>>> versions of X. (to not even speak of MTRR)
>>>
>>> Having this as a regular config option just no longer makes sense.
>>>
>>> This patch relegates CONFIG_X86_PAT to the EMBEDDED category so
>>> ultra-embedded can still disable it if they really need to.
>>>
>>
>> Should we combine this with removing the whitelist (which is largely
>> vestigial at this point) and replace it with a blacklist (possibly
>> empty)? I still haven't seen any evidence that there are any CPUs
>> which have problems, and PAT support go back all the way to Pentium
>> III -- and page table attributes can be used all the way back to 386,
>> it just excludes the WC type.
>
> I would be in favor of that; other operating systems have been using
> pat everywhere since the pII days anyway.
Fine to me too. We only made it a whitelist to reduce the degrees of
freedom early in the implementation - it stuck around needlessly long.
Ingo