Display Intel Dynamic Acceleration feature in /proc/cpuinfo

PATCH In review Venki Pallipadi 6 participants 27 messages May 23, 2007 – May 30, 2007

Share & tools

Venki Pallipadi

author

2007-05-23 22:49 UTC #0 lore raw

PATCH 1/1 Display Intel Dynamic Acceleration feature in /proc/cpuinfo

Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.

Refer to Intel Software Developer's Manual for more details about the feature.

Signed-off-by Venkatesh Pallipadi <[email protected]>

arch/i386/kernel/cpu/proc.c +1 -1

Index: linux-2.6.22-rc-mm/arch/i386/kernel/cpu/proc.c
===================================================================
@@ -41,7 +41,7 @@ static int show_cpuinfo(struct seq_file 
 		"cxmmx", "k6_mtrr", "cyrix_arr", "centaur_mcr",
 		NULL, NULL, NULL, NULL,
 		"constant_tsc", "up", NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"ida", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 
 		/* Intel-defined (#2) */

arch/x86_64/kernel/setup.c +1 -1

Index: linux-2.6.22-rc-mm/arch/x86_64/kernel/setup.c
===================================================================
@@ -949,7 +949,7 @@ static int show_cpuinfo(struct seq_file 
 		/* Other (Linux-defined) */
 		"cxmmx", NULL, "cyrix_arr", "centaur_mcr", NULL,
 		"constant_tsc", NULL, NULL,
-		"up", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"up", NULL, NULL, NULL, "ida", NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

include/asm-i386/cpufeature.h +1 -0

Index: linux-2.6.22-rc-mm/include/asm-i386/cpufeature.h
===================================================================
@@ -81,6 +81,7 @@
 #define X86_FEATURE_BTS		(3*32+13)  /* Branch Trace Store */
 #define X86_FEATURE_LAPIC_TIMER_BROKEN (3*32+ 14) /* lapic timer broken in C1 */
 #define X86_FEATURE_SYNC_RDTSC	(3*32+15)  /* RDTSC synchronizes the CPU */
+#define X86_FEATURE_IDA		(3*32+16)  /* Intel Dynamic Acceleration */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */

include/asm-x86_64/cpufeature.h +1 -0

Index: linux-2.6.22-rc-mm/include/asm-x86_64/cpufeature.h
===================================================================
@@ -70,6 +70,7 @@
 #define X86_FEATURE_ARCH_PERFMON (3*32+9) /* Intel Architectural PerfMon */
 #define X86_FEATURE_PEBS	(3*32+10) /* Precise-Event Based Sampling */
 #define X86_FEATURE_BTS		(3*32+11) /* Branch Trace Store */
+#define X86_FEATURE_IDA		(3*32+12) /* Intel Dynamic Acceleration */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (ecx), word 4 */
 #define X86_FEATURE_XMM3	(4*32+ 0) /* Streaming SIMD Extensions-3 */

arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c +12 -1

Index: linux-2.6.22-rc-mm/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===================================================================
@@ -58,6 +58,7 @@ enum {
 
 #define INTEL_MSR_RANGE		(0xffff)
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY	(0x1)
+#define CPUID_6_EAX_IDA_CAPABILITY		(0x2)
 
 struct acpi_cpufreq_data {
 	struct acpi_processor_performance *acpi_data;

@@ -699,10 +700,20 @@ static int acpi_cpufreq_cpu_init(struct 
 
 	/* Check for APERF/MPERF support in hardware */
 	if (c->x86_vendor == X86_VENDOR_INTEL && c->cpuid_level >= 6) {
-		unsigned int ecx;
+		unsigned int eax, ecx;
 		ecx = cpuid_ecx(6);
 		if (ecx & CPUID_6_ECX_APERFMPERF_CAPABILITY)
 			acpi_cpufreq_driver.getavg = get_measured_perf;
+
+		eax = cpuid_eax(6);
+		if (eax & CPUID_6_EAX_IDA_CAPABILITY) {
+			unsigned int i;
+
+			for_each_cpu_mask(i, policy->cpus) {
+				struct cpuinfo_x86 *c = &cpu_data[i];
+				set_bit(X86_FEATURE_IDA, c->x86_capability);
+			}
+		}
 	}
 
 	dprintk("CPU%u - ACPI performance management activated.\n", cpu);

Andrew Morton

2007-05-24 20:55 UTC #1 lore raw

Quoted 2 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…

Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.

So you're saying that the cpufreq code in Linus's tree aleady supports IDA? If so, this is a 2.6.22 patch, isn't it?

Dave Jones

2007-05-24 21:01 UTC #2 lore raw

Quoted 10 lines · Andrew Morton

Quoted 2 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…
Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.
So you're saying that the cpufreq code in Linus's tree aleady supports IDA? If so, this is a 2.6.22 patch, isn't it?
From my limited understanding[*], ida is the "We're single threaded,

disable the 2nd core, and clock the first core faster" magic. It doesn't need code-changes, as its all done in hardware afaik.

identifying & exporting the flags on earlier kernels should be harmless, but not really 'mustfix'.

Dave

[*] As in I've read about this more on the inquirer etc than I have on Intel docs so far. ;-)

Signature · 1 line

http://www.codemonkey.org.uk

Andi Kleen

2007-05-24 21:08 UTC #3 lore raw

Quoted 7 lines · On Thursday 24 May 2007 23:01:04 Dave Jones wrote:

Quoted 6 lines · Andrew Morton
Quoted 2 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…
Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.

Quoted 6 lines

Quoted 2 lines
So you're saying that the cpufreq code in Linus's tree aleady supports IDA? If so, this is a 2.6.22 patch, isn't it?
From my limited understanding[*], ida is the "We're single threaded, disable the 2nd core, and clock the first core faster" magic. It doesn't need code-changes, as its all done in hardware afaik.

P0 is somewhat visible to software, but it should be pretty transparent

Quoted 3 lines

identifying & exporting the flags on earlier kernels should be harmless, but not really 'mustfix'.

I think it's generally a good idea to push cpuinfo flags in earliest as possible; just make sure we actually use the final name (so that we don't get into a pni->sse3 mess again)

-Andi

Venki Pallipadi

author

2007-05-24 21:16 UTC #4 lore raw

Quoted 5 lines · Andi Kleen

I think it's generally a good idea to push cpuinfo flags in earliest as possible; just make sure we actually use the final name (so that we don't get into a pni->sse3 mess again)

ida is official name as in the Software Developer's Manual now. So, should not be a issue unless marketing folks change their mind in future :-)

Thanks,
Venki

Andi Kleen

2007-05-24 21:25 UTC #5 lore raw

Quoted 9 lines · On Thursday 24 May 2007 23:13:37 Venki Pallipadi wrote:

Quoted 5 lines · Andi Kleen
I think it's generally a good idea to push cpuinfo flags in earliest as possible; just make sure we actually use the final name (so that we don't get into a pni->sse3 mess again)
ida is official name as in the Software Developer's Manual now. So, should not be a issue unless marketing folks change their mind in future :-)

Well they did sometimes in the past.

But actually reading the patch: it seems weird to detect the flag in acpi-cpufreq and essentially change /proc/cpuinfo when a module is loaded. Why not in the intel setup function? And why is it not in the standard CPUID 1 features mask anyways?

-Andi

Venki Pallipadi

author

2007-05-24 21:31 UTC #6 lore raw

Quoted 11 lines · Andi Kleen

Quoted 9 lines · On Thursday 24 May 2007 23:13:37 Venki Pallipadi wrote:
Quoted 5 lines · Andi Kleen
I think it's generally a good idea to push cpuinfo flags in earliest as possible; just make sure we actually use the final name (so that we don't get into a pni->sse3 mess again)
ida is official name as in the Software Developer's Manual now. So, should not be a issue unless marketing folks change their mind in future :-)

Quoted 7 lines

Well they did sometimes in the past.
But actually reading the patch: it seems weird to detect the flag in acpi-cpufreq and essentially change /proc/cpuinfo when a module is loaded. Why not in the intel setup function? And why is it not in the standard CPUID 1 features mask anyways?

I can do it in intel setup function. But, the feature may not be activated unless the driver is loaded. Going by the hardware capability point of view, we can do it in setup function.

The feature appears in CPUID 6 (called Power Management Leaf) instead of regular CPUID 1 features.

Thanks,
Venki

Dave Jones

2007-05-24 21:38 UTC #7 lore raw

Quoted 7 lines · Venki Pallipadi

Quoted 4 lines
But actually reading the patch: it seems weird to detect the flag in acpi-cpufreq and essentially change /proc/cpuinfo when a module is loaded. Why not in the intel setup function? And why is it not in the standard CPUID 1 features mask anyways?
I can do it in intel setup function. But, the feature may not be activated unless the driver is loaded.

The same could be said about est, vmx, and probably some others ;-)

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Andi Kleen

2007-05-24 21:57 UTC #8 lore raw

In reply to Venki Pallipadi

Quoted 3 lines

I can do it in intel setup function. But, the feature may not be activated unless the driver is loaded.

That would put users in a chicken and egg situation: they cannot know they need to load a driver to go faster. It's better to display it always.

-Andi

H. Peter Anvin

2007-05-24 23:04 UTC #9 lore raw

In reply to Venki Pallipadi

Quoted 8 lines · Venki Pallipadi

I can do it in intel setup function. But, the feature may not be activated unless the driver is loaded. Going by the hardware capability point of view, we can do it in setup function.
The feature appears in CPUID 6 (called Power Management Leaf) instead of regular CPUID 1 features.

This sounds like it should be a new CPUID word?

-hpa

Pallipadi, Venkatesh

author

2007-05-24 23:13 UTC #10 lore raw

Quoted 17 lines

-----Original Message-----
From: H. Peter Anvin [mailto:[email protected]]
Sent: Thursday, May 24, 2007 4:04 PM
To: Pallipadi, Venkatesh
Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel
Subject: Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Quoted 2 lines · Venki Pallipadi
I can do it in intel setup function. But, the feature may
not be activated
Quoted 3 lines
unless the driver is loaded. Going by the hardware capability point of view, we can do it in setup function.

Quoted 7 lines

Quoted 1 line
The feature appears in CPUID 6 (called Power Management
Leaf) instead of
Quoted 2 lines
regular CPUID 1 features.
This sounds like it should be a new CPUID word?

Yes. But it only has 3 features defined right now. 2 in EAX and one in ECX. Should I use 2 new words for these bits or just use the software defined bits as in my earlier patch?

Thanks,
Venki

H. Peter Anvin

2007-05-24 23:23 UTC #11 lore raw

Quoted 5 lines · Venkatesh

Yes. But it only has 3 features defined right now. 2 in EAX and one in ECX. Should I use 2 new words for these bits or just use the software defined bits as in my earlier patch?

Oh for heaven's sake. Could you please do the world a favour and shoot your CPUID architect?

The real answer depends on how you expect it to grow in the future. Intel has a piss-poor record at being consistent in this matter, which speaks for a more ad hoc approach, but if there really is a sane growth path going forward, then go ahead and define two new words.

-hpa

Pallipadi, Venkatesh

author

2007-05-25 00:00 UTC #12 lore raw

Quoted 18 lines

-----Original Message-----
From: H. Peter Anvin [mailto:[email protected]]
Sent: Thursday, May 24, 2007 4:23 PM
To: Pallipadi, Venkatesh
Cc: Andi Kleen; Dave Jones; Andrew Morton; Brown, Len; linux-kernel
Subject: Re: [PATCH] Display Intel Dynamic Acceleration feature in /proc/cpuinfo
Quoted 2 lines · Venkatesh
Yes. But it only has 3 features defined right now. 2 in EAX
and one in
Quoted 3 lines
ECX. Should I use 2 new words for these bits or just use the software defined bits as in my earlier patch?

Quoted 8 lines

Oh for heaven's sake. Could you please do the world a favour and shoot your CPUID architect?
The real answer depends on how you expect it to grow in the future. Intel has a piss-poor record at being consistent in this matter, which speaks for a more ad hoc approach, but if there really is a sane growth path going forward, then go ahead and define two new words.

The way new Intel features are being exposed in CPUID is kind of changing.
Now we have different CPUID leafs for different kind of features with each of them growing much slowly.
I mean, there is
monitor-mwait related features in CPUID 5
powermanagement features in CPUID 6 EAX, ECX
Perfmon features in CPUID 10

This does not fit well with the way we use the feature words in Linux. Probably
it is better to have one new word for new Intel features and add bits from all
CPUIDs as they come. I will take a look at all the other fields and try for
a better solution than adding new words for different CPUIDs like above.

Thanks,
Venki

H. Peter Anvin

2007-05-25 00:04 UTC #13 lore raw

Quoted 2 lines · Venkatesh

The way new Intel features are being exposed in CPUID is kind of changing.

Changing is a VERY BAD THING when it comes to something like CPUID.

Quoted 6 lines

Now we have different CPUID leafs for different kind of features with each of them growing much slowly.
I mean, there is
monitor-mwait related features in CPUID 5
powermanagement features in CPUID 6 EAX, ECX
Perfmon features in CPUID 10

Again, this is bad.

Quoted 1 line

This does not fit well with the way we use the feature words in Linux.

No, it doesn't... nor for anyone else who wants a compact representation of this kind of information.

If they grow slowly from the bottom, I guess we could simply allocate space in the vector byte by byte instead. Either way, it means more work whenever anything has to change.

-hpa

Venki Pallipadi

author

2007-05-30 00:56 UTC #14 lore raw

Quoted 5 lines · H. Peter Anvin

If they grow slowly from the bottom, I guess we could simply allocate space in the vector byte by byte instead. Either way, it means more work whenever anything has to change.

hpa,

Below patch adds a new word for feature bits that willb eused for all Intel features that may be spread around in CPUID leafs like 0x6, 0xA, etc. I added "ida" bit first into this word. I will send an incremental patch to move ARCH_PERFMON bit and any other feature bits in these leaf subsequently. The patch is against newsetup git tree.

Please apply.

Thanks,
Venki

Use a new CPU feature word to cover all Intel features that are spread around in different CPUID leafs like 0x5, 0x6 and 0xA. Make this
feature detection code common across i386 and x86_64.

Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver.

Refer to Intel Software Developer's Manual for more details about the feature.

Signed-off-by Venkatesh Pallipadi <[email protected]>

include/asm-i386/cpufeature.h +6 -2

Index: linux-2.6/include/asm-i386/cpufeature.h
===================================================================
@@ -12,7 +12,7 @@
 #endif
 #include <asm/required-features.h>
 
-#define NCAPINTS	7	/* N 32-bit words worth of info */
+#define NCAPINTS	8	/* N 32-bit words worth of info */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (edx), word 0 */
 #define X86_FEATURE_FPU		(0*32+ 0) /* Onboard FPU */

@@ -109,6 +109,9 @@
 #define X86_FEATURE_LAHF_LM	(6*32+ 0) /* LAHF/SAHF in long mode */
 #define X86_FEATURE_CMP_LEGACY	(6*32+ 1) /* If yes HyperThreading not valid */
 
+/* More extended Intel flags: From various new CPUID levels like 0x6, 0xA etc */
+#define X86_FEATURE_IDA		(7*32+ 0) /* Intel Dynamic Acceleration */
+
 #define cpu_has(c, bit)							\
 	(__builtin_constant_p(bit) &&					\
 	 ( (((bit)>>5)==0 && (1UL<<((bit)&31) & REQUIRED_MASK0)) ||	\

@@ -117,7 +120,8 @@
 	   (((bit)>>5)==3 && (1UL<<((bit)&31) & REQUIRED_MASK3)) ||	\
 	   (((bit)>>5)==4 && (1UL<<((bit)&31) & REQUIRED_MASK4)) ||	\
 	   (((bit)>>5)==5 && (1UL<<((bit)&31) & REQUIRED_MASK5)) ||	\
-	   (((bit)>>5)==6 && (1UL<<((bit)&31) & REQUIRED_MASK6)) )	\
+	   (((bit)>>5)==6 && (1UL<<((bit)&31) & REQUIRED_MASK6)) ||	\
+	   (((bit)>>5)==7 && (1UL<<((bit)&31) & REQUIRED_MASK7)) )	\
 	  ? 1 :								\
 	  test_bit(bit, (c)->x86_capability))
 #define boot_cpu_has(bit)	cpu_has(&boot_cpu_data, bit)

arch/i386/kernel/cpu/proc.c +6 -0

Index: linux-2.6/arch/i386/kernel/cpu/proc.c
===================================================================
@@ -65,6 +65,12 @@
 		"osvw", "ibs", NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+
+		/* Intel-defined (#3) */
+		"ida", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 	};
 	static const char * const x86_power_flags[] = {
 		"ts",	/* temperature sensor */

arch/x86_64/kernel/setup.c +7 -0

Index: linux-2.6/arch/x86_64/kernel/setup.c
===================================================================
@@ -699,6 +699,7 @@
 	/* Cache sizes */
 	unsigned n;
 
+	init_additional_intel_features(c);
 	init_intel_cacheinfo(c);
 	if (c->cpuid_level > 9 ) {
 		unsigned eax = cpuid_eax(10);

@@ -973,6 +974,12 @@
 		"osvw", "ibs", NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+
+		/* Intel-defined (#3) */
+		"ida", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 	};
 	static char *x86_power_flags[] = { 
 		"ts",	/* temperature sensor */

include/asm-i386/required-features.h +1 -0

Index: linux-2.6/include/asm-i386/required-features.h
===================================================================
@@ -56,5 +56,6 @@
 #define REQUIRED_MASK4	0
 #define REQUIRED_MASK5	0
 #define REQUIRED_MASK6	0
+#define REQUIRED_MASK7	0
 
 #endif

include/asm-x86_64/required-features.h +1 -0

Index: linux-2.6/include/asm-x86_64/required-features.h
===================================================================
@@ -42,5 +42,6 @@
 #define REQUIRED_MASK4	0
 #define REQUIRED_MASK5	0
 #define REQUIRED_MASK6	0
+#define REQUIRED_MASK7	0
 
 #endif

arch/i386/kernel/cpu/intel.c +1 -0

Index: linux-2.6/arch/i386/kernel/cpu/intel.c
===================================================================
@@ -120,6 +120,7 @@
 #endif
 
 	select_idle_routine(c);
+	init_additional_intel_features(c);
 	l2 = init_intel_cacheinfo(c);
 	if (c->cpuid_level > 9 ) {
 		unsigned eax = cpuid_eax(10);

arch/i386/kernel/cpu/intel_features.c new file +22 -0

Index: linux-2.6/arch/i386/kernel/cpu/intel_features.c
===================================================================
@@ -0,0 +1,22 @@
+
+/*
+ *	Routines to indentify additional Intel cpu features
+ *	Features in word 7
+ */
+
+#include <linux/cpu.h>
+
+#include <asm/processor.h>
+
+#define CPUID_6_EAX_IDA		0x2
+
+void __cpuinit init_additional_intel_features(struct cpuinfo_x86 *c)
+{
+	unsigned int eax;
+
+	if (c->cpuid_level >= 6) {
+		eax = cpuid_eax(6);
+		if (eax & CPUID_6_EAX_IDA)
+			set_bit(X86_FEATURE_IDA, c->x86_capability);
+	}
+}

arch/i386/kernel/cpu/Makefile +1 -1

Index: linux-2.6/arch/i386/kernel/cpu/Makefile
===================================================================
@@ -8,7 +8,7 @@
 obj-y	+=	cyrix.o
 obj-y	+=	centaur.o
 obj-y	+=	transmeta.o
-obj-y	+=	intel.o intel_cacheinfo.o
+obj-y	+=	intel.o intel_cacheinfo.o intel_features.o
 obj-y	+=	rise.o
 obj-y	+=	nexgen.o
 obj-y	+=	umc.o

arch/x86_64/kernel/Makefile +2 -0

Index: linux-2.6/arch/x86_64/kernel/Makefile
===================================================================
@@ -44,6 +44,7 @@
 
 obj-y				+= topology.o
 obj-y				+= intel_cacheinfo.o
+obj-y				+= intel_features.o
 obj-y				+= pcspeaker.o
 
 CFLAGS_vsyscall.o		:= $(PROFILING) -g0

@@ -55,6 +56,7 @@
 topology-y                     += ../../i386/kernel/topology.o
 microcode-$(subst m,y,$(CONFIG_MICROCODE))  += ../../i386/kernel/microcode.o
 intel_cacheinfo-y		+= ../../i386/kernel/cpu/intel_cacheinfo.o
+intel_features-y		+= ../../i386/kernel/cpu/intel_features.o
 quirks-y			+= ../../i386/kernel/quirks.o
 i8237-y				+= ../../i386/kernel/i8237.o
 msr-$(subst m,y,$(CONFIG_X86_MSR))  += ../../i386/kernel/msr.o

include/asm-i386/processor.h +1 -0

Index: linux-2.6/include/asm-i386/processor.h
===================================================================
@@ -119,6 +119,7 @@
 extern void identify_boot_cpu(void);
 extern void identify_secondary_cpu(struct cpuinfo_x86 *);
 extern void print_cpu_info(struct cpuinfo_x86 *);
+extern void init_additional_intel_features(struct cpuinfo_x86 *c);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern unsigned short num_cache_leaves;

include/asm-x86_64/processor.h +1 -0

Index: linux-2.6/include/asm-x86_64/processor.h
===================================================================
@@ -100,6 +100,7 @@
 
 extern void identify_cpu(struct cpuinfo_x86 *);
 extern void print_cpu_info(struct cpuinfo_x86 *);
+extern void init_additional_intel_features(struct cpuinfo_x86 *c);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern unsigned short num_cache_leaves;

Venki Pallipadi

author

2007-05-24 21:13 UTC #15 lore raw

In reply to Dave Jones

Quoted 7 lines · Dave Jones

Quoted 6 lines · Andrew Morton
Quoted 2 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…
Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.

Quoted 6 lines

Quoted 2 lines
So you're saying that the cpufreq code in Linus's tree aleady supports IDA? If so, this is a 2.6.22 patch, isn't it?
From my limited understanding[*], ida is the "We're single threaded, disable the 2nd core, and clock the first core faster" magic. It doesn't need code-changes, as its all done in hardware afaik.

IDA state will appear as a new highest freq P-state (P0) and when software requests that frequency, hardware can provide a higher frequency than that oppurtunistically and transparently.

The current cpufreq code will detect this new state and enter that state when CPU is busy.

Quoted 4 lines

identifying & exporting the flags on earlier kernels should be harmless, but not really 'mustfix'.

Agree with Dave that it is not a mustfix. As the patch is pretty harmless would be nice to have in 2.6.22.

Thanks,
Venki

Andrew Morton

2007-05-24 22:03 UTC #16 lore raw

In reply to Venki Pallipadi

Quoted 25 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…

Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.
Refer to Intel Software Developer's Manual for more details about the feature.
Signed-off-by Venkatesh Pallipadi <[email protected]>
Index: linux-2.6.22-rc-mm/arch/i386/kernel/cpu/proc.c
===================================================================
arch/i386/kernel/cpu/proc.c +1 -1
@@ -41,7 +41,7 @@ static int show_cpuinfo(struct seq_file 
 		"cxmmx", "k6_mtrr", "cyrix_arr", "centaur_mcr",
 		NULL, NULL, NULL, NULL,
 		"constant_tsc", "up", NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"ida", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 
 		/* Intel-defined (#2) */
Index: linux-2.6.22-rc-mm/arch/x86_64/kernel/setup.c
===================================================================

arch/x86_64/kernel/setup.c static int show_cpuinfo(struct seq_file · line 954

Quoted 7 lines

arch/x86_64/kernel/setup.c +1 -1

@@ -949,7 +949,7 @@ static int show_cpuinfo(struct seq_file 
 		/* Other (Linux-defined) */
 		"cxmmx", NULL, "cyrix_arr", "centaur_mcr", NULL,
 		"constant_tsc", NULL, NULL,
-		"up", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"up", NULL, NULL, NULL, "ida", NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,

Ho hum. This clashes with hpa's git-newsetup tree, which goes for a great tromp through the cpuinfo implementation.

Hunk #1 FAILED at 41.
1 out of 1 hunk FAILED -- saving rejects to file arch/i386/kernel/cpu/proc.c.rej patching file arch/x86_64/kernel/setup.c
Hunk #1 FAILED at 951.
1 out of 1 hunk FAILED -- saving rejects to file arch/x86_64/kernel/setup.c.rej patching file include/asm-i386/cpufeature.h
Hunk #1 FAILED at 81.
1 out of 1 hunk FAILED -- saving rejects to file include/asm-i386/cpufeature.h.rej patching file include/asm-x86_64/cpufeature.h
Hunk #1 FAILED at 70.
1 out of 1 hunk FAILED -- saving rejects to file include/asm-x86_64/cpufeature.h.rej

I'm not sure I can be bothered repairing all that at present. I think I'll go and hide until it becomes somebody else's problem.

@@ -23,13 +23,14 @@ static int show_cpuinfo(struct seq_file

                "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
                "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
                "pat", "pse36", "pn", "clflush", NULL, "dts", "acpi", "mmx",

- "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe",
+ "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", NULL,

Venki Pallipadi

author

2007-05-24 22:11 UTC #17 lore raw

Quoted 22 lines · Andrew Morton

Quoted 19 lines · On Wed, 23 May 2007 15:46:37 -0700 Venki Pallipadi…
Display Intel Dynamic Acceleration feature in /proc/cpuinfo. This feature will be enabled automatically by current acpi-cpufreq driver and cpufreq.
Refer to Intel Software Developer's Manual for more details about the feature.
Signed-off-by Venkatesh Pallipadi <[email protected]>
Index: linux-2.6.22-rc-mm/arch/i386/kernel/cpu/proc.c
===================================================================
arch/i386/kernel/cpu/proc.c +1 -1
@@ -41,7 +41,7 @@ static int show_cpuinfo(struct seq_file 
 		"cxmmx", "k6_mtrr", "cyrix_arr", "centaur_mcr",
 		NULL, NULL, NULL, NULL,
 		"constant_tsc", "up", NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"ida", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 

Quoted 17 lines

arch/x86_64/kernel/setup.c static int show_cpuinfo(struct seq_file · line 954
Quoted 13 lines
arch/i386/kernel/cpu/proc.c +0 -0
 		/* Intel-defined (#2) */
Index: linux-2.6.22-rc-mm/arch/x86_64/kernel/setup.c
===================================================================
arch/x86_64/kernel/setup.c +1 -1
@@ -949,7 +949,7 @@ static int show_cpuinfo(struct seq_file 
 		/* Other (Linux-defined) */
 		"cxmmx", NULL, "cyrix_arr", "centaur_mcr", NULL,
 		"constant_tsc", NULL, NULL,
-		"up", NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+		"up", NULL, NULL, NULL, "ida", NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
 		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
Ho hum. This clashes with hpa's git-newsetup tree, which goes for a great tromp through the cpuinfo implementation.

Hmm.. Will move feature detection to setup routines and will also refresh the patch against latest mm and resend it

Thanks,
Venki

H. Peter Anvin

2007-05-24 22:16 UTC #18 lore raw

Quoted 4 lines · Venki Pallipadi

Hmm.. Will move feature detection to setup routines and will also refresh the patch against latest mm and resend it

If you could send a patch against my git.newsetup instead, I'll merge into that tree.

http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=summary

-hpa

H. Peter Anvin

2007-05-24 22:15 UTC #19 lore raw

In reply to Andrew Morton

Quoted 4 lines · Andrew Morton

I'm not sure I can be bothered repairing all that at present. I think I'll go and hide until it becomes somebody else's problem.

I'll fix it.

Quoted 10 lines

(quoted diff) +1 -1

@@ -23,13 +23,14 @@ static int show_cpuinfo(struct seq_file 
                "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
                "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
                "pat", "pse36", "pn", "clflush", NULL, "dts", "acpi", "mmx",
-               "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe",
+               "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", NULL,

pbe collides with abuse by at least two vendors (AMD and Cyrix/Centaur/VIA) of this bit for 3DNow. I don't know if that applies only to the chips that don't support extended CPUID levels, but I'm fairly sure that we don't handle that correctly in the vendor-specific handlers.

I guess for now we can just unconditionally disable that bit in those vendor routines, with a note saying that if there are such chips supporting PBE then more sophisticated logic needs to be implemented.

-hpa

Dave Jones

2007-05-24 22:42 UTC #20 lore raw

Quoted 2 lines · H. Peter Anvin

pbe collides with abuse by at least two vendors (AMD and Cyrix/Centaur/VIA) of this bit for 3DNow.

Unless I'm mistaken,

pbe comes from cpuid level 1

3dnow comes from cpuid level 0x80000001
though I did notice that amd have it in edx, whilst via have it in ecx curiously.

Dave

Signature · 1 line

http://www.codemonkey.org.uk

H. Peter Anvin

2007-05-24 22:52 UTC #21 lore raw

Quoted 5 lines · Dave Jones

Quoted 2 lines · H. Peter Anvin
pbe collides with abuse by at least two vendors (AMD and Cyrix/Centaur/VIA) of this bit for 3DNow.

Quoted 7 lines

Unless I'm mistaken,
pbe comes from cpuid level 1
3dnow comes from cpuid level 0x80000001
though I did notice that amd have it in edx, whilst via have it in ecx curiously.

edx is correct.

What you're describing is correct for later-level AMD/Cyrix chips, however, when 3DNow! was first introduced they foolishly squatted on the Intel-assigned CPUID flags.

However, I have audited all the vendor initialization paths, and we kill off that CPUID bit in all the places that matter.

-hpa

Dave Jones

2007-05-24 23:06 UTC #22 lore raw

Quoted 3 lines · H. Peter Anvin

What you're describing is correct for later-level AMD/Cyrix chips, however, when 3DNow! was first introduced they foolishly squatted on the Intel-assigned CPUID flags.

Hmm, the 3dnow spec (doc 21928e) has it in the right place, and I don't see anything in the errata docs I have.

Do you have more info on this? If its true, I'd like to make x86info aware of it.

Dave

Signature · 1 line

http://www.codemonkey.org.uk

H. Peter Anvin

2007-05-24 23:12 UTC #23 lore raw

Quoted 10 lines · Dave Jones

Quoted 3 lines · H. Peter Anvin
What you're describing is correct for later-level AMD/Cyrix chips, however, when 3DNow! was first introduced they foolishly squatted on the Intel-assigned CPUID flags.
Hmm, the 3dnow spec (doc 21928e) has it in the right place, and I don't see anything in the errata docs I have.
Do you have more info on this? If its true, I'd like to make x86info aware of it.

I don't have exact details, but I have sent off a query to someone I know that probably *does* know the exact details.

Linux does the right thing, as it will turn off bit 31 if it seems AMD, Cyrix or Centaur as the vendor ID (VIA still uses the Centaur VID apparently.)

-hpa

Alan Cox

2007-05-24 23:46 UTC #24 lore raw

In reply to Dave Jones

Quoted 5 lines · On Thu, 24 May 2007 18:41:54 -0400 Dave Jones <[email protected]> wrote:

Quoted 2 lines · H. Peter Anvin
pbe collides with abuse by at least two vendors (AMD and Cyrix/Centaur/VIA) of this bit for 3DNow.

Quoted 7 lines

Unless I'm mistaken,
pbe comes from cpuid level 1
3dnow comes from cpuid level 0x80000001
though I did notice that amd have it in edx, whilst via have it in ecx curiously.

The older AMD docs (CPU rev guide) list bit 31 of both 0x80000001 and 0x00000001 as 3dnow

All their example code/docs say to use 0x80000001

H. Peter Anvin

2007-05-24 23:53 UTC #25 lore raw

Quoted 6 lines · Alan Cox

The older AMD docs (CPU rev guide) list bit 31 of both 0x80000001 and 0x00000001 as 3dnow
All their example code/docs say to use 0x80000001

I don't have access to any AM2 systems, but the bit is definitely set on socket 939 Athlon X2 ("model 43").

-hpa

H. Peter Anvin

2007-05-24 22:28 UTC #26 lore raw

In reply to Andrew Morton

Quoted 10 lines · Andrew Morton

(quoted diff) +1 -1

@@ -23,13 +23,14 @@ static int show_cpuinfo(struct seq_file 
                "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
                "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
                "pat", "pse36", "pn", "clflush", NULL, "dts", "acpi", "mmx",
-               "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe",
+               "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", NULL,

I just went through all the codepaths, and we filter this bit in all the appropriate places, so it's safe to display. I've added it to both i386 and x86-64 in the git.newsetup tree (the two were inconsistent.)

-hpa