[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20070405225141.GA9112@tweety.malo>
Date: Fri, 6 Apr 2007 00:51:41 +0200
From: Andreas Herrmann <aherrman@...or.de>
To: Andi Kleen <ak@...e.de>, "H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org, andreas.herrmann3@....com
Subject: [PATCH RFC] x86: clear X86_FEATURE_MWAIT for AMD Fam10 CPU
Hi,
I send this as RFC because I won't manage it to test it
before end of Easter but want to have a consensus about
how the final patch should look like.
Andi,
what do you finally prefer?
(1) Something like the attached patch or
(2) a version which keeps to the MWAIT flag for Fam10 but
introduces an X86_FEATURE_MWAIT_DOESNT_SAVE_POWER as you
suggested.
An idle=mwait kernel parameter could (and should) be introduced
with both alternatives.
Meanwhile I think it would suffice to do (1) and issue another
cpuid if idle=mwait was used to select mwait_idle.
Regards,
Andreas
--
diff --git a/arch/i386/kernel/cpu/amd.c b/arch/i386/kernel/cpu/amd.c
index 2d47db4..4e01262 100644
--- a/arch/i386/kernel/cpu/amd.c
+++ b/arch/i386/kernel/cpu/amd.c
@@ -228,6 +228,9 @@ #define CBAR_KEY (0X000000CB)
}
switch (c->x86) {
+ case 16:
+ clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
+ break;
case 15:
set_bit(X86_FEATURE_K8, c->x86_capability);
break;
diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index 3d98b69..f53ee6c 100644
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -583,6 +583,10 @@ #endif
if (c->x86 == 15 && ((level >= 0x0f48 && level < 0x0f50) || level >= 0x0f58))
set_bit(X86_FEATURE_REP_GOOD, &c->x86_capability);
+ /* disable use of mwait on idle */
+ if (c->x86 == 16)
+ clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
+
/* Enable workaround for FXSAVE leak */
if (c->x86 >= 6)
set_bit(X86_FEATURE_FXSAVE_LEAK, &c->x86_capability);
-
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