--
Tomas Szepe <sz...@pinerecords.com>
diff -urN a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig 2004-01-04 03:10:01.000000000 +0100
+++ b/arch/i386/Kconfig 2004-01-04 03:06:09.000000000 +0100
@@ -231,6 +231,13 @@
correct cache shift, and applies any applicable Pentium III
optimizations.
+config MPENTIUMM
+ bool "Pentium M (Banias/Centrino)"
+ help
+ Select this for Intel Pentium M chips. This option enables
+ compile flags optimized for the chip, uses the correct cache
+ shift, and applies any applicable Pentium III/IV optimizations.
+
config MK6
bool "K6/K6-II/K6-III"
help
@@ -330,7 +337,7 @@
default "7" if MPENTIUM4 || X86_GENERIC
default "4" if MELAN || M486 || M386
default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
- default "6" if MK7 || MK8
+ default "6" if MPENTIUMM || MK7 || MK8
config RWSEM_GENERIC_SPINLOCK
bool
@@ -379,17 +386,17 @@
config X86_GOOD_APIC
bool
- depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+ depends on MK7 || MPENTIUMM || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
default y
config X86_INTEL_USERCOPY
bool
- depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+ depends on MPENTIUMM || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
default y
config X86_USE_PPRO_CHECKSUM
bool
- depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+ depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUMM || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
default y
config X86_USE_3DNOW
@@ -512,7 +519,7 @@
config X86_TSC
bool
- depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+ depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUMM || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
default y
config X86_MCE
diff -urN a/arch/i386/Makefile b/arch/i386/Makefile
--- a/arch/i386/Makefile 2003-09-28 11:38:05.000000000 +0200
+++ b/arch/i386/Makefile 2004-01-04 03:02:52.000000000 +0100
@@ -35,6 +35,7 @@
cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686)
cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686)
cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686)
+cflags-$(CONFIG_MPENTIUMM) += $(call check_gcc,-march=pentium4,-march=i686)
cflags-$(CONFIG_MK6) += $(call check_gcc,-march=k6,-march=i586)
# Please note, that patches that add -march=athlon-xp and friends are pointless.
# They make zero difference whatsosever to performance at this time.
diff -urN a/include/asm-i386/module.h b/include/asm-i386/module.h
--- a/include/asm-i386/module.h 2003-08-23 01:52:22.000000000 +0200
+++ b/include/asm-i386/module.h 2004-01-04 03:08:17.000000000 +0100
@@ -28,6 +28,8 @@
#define MODULE_PROC_FAMILY "PENTIUMIII "
#elif defined CONFIG_MPENTIUM4
#define MODULE_PROC_FAMILY "PENTIUM4 "
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY "PENTIUMM "
#elif defined CONFIG_MK6
#define MODULE_PROC_FAMILY "K6 "
#elif defined CONFIG_MK7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
P-M is not a P4 core, it's an enhanced PIII core.
SSE2 was added, but compiler support for SSE2 f.p.
math shouldn't matter for the kernel.
Using P4 optimisations on a P-M may actually reduce
performance, due to the different micro-architectures.
(P4 made shifts and some leas more expensive, and
simple add/and/sub/etc less expensive.)
IOW, don't lie to the compiler and pretend P-M == P4
with that -march=pentium4.
And since P-M doesn't do SMP, does cache line size even
matter? There are no locks to protect from ping-ponging.
/Mikael
> IOW, don't lie to the compiler and pretend P-M == P4
> with that -march=pentium4.
What do you recommend to use as march then? There is
no pentiumm subarch support in gcc yet; I was convinced
p4 was the closest match.
--
Tomas Szepe <sz...@pinerecords.com>
march=pentium3 is the closest safe choice, at least
until gcc implements P-M specific support.
/Mikael
> On Date: Sun, 4 Jan 2004 13:33:58 +0100, Tomas Szepe wrote:
> > > IOW, don't lie to the compiler and pretend P-M == P4
> > > with that -march=pentium4.
> >
> > What do you recommend to use as march then? There is
> > no pentiumm subarch support in gcc yet; I was convinced
> > p4 was the closest match.
>
> march=pentium3 is the closest safe choice, at least
> until gcc implements P-M specific support.
Thanks, here's the updated patch.
--
Tomas Szepe <sz...@pinerecords.com>
--- a/arch/i386/Makefile 2003-09-28 11:38:05.000000000 +0200
+++ b/arch/i386/Makefile 2004-01-04 03:02:52.000000000 +0100
@@ -35,6 +35,7 @@
cflags-$(CONFIG_MPENTIUMII) += $(call check_gcc,-march=pentium2,-march=i686)
cflags-$(CONFIG_MPENTIUMIII) += $(call check_gcc,-march=pentium3,-march=i686)
cflags-$(CONFIG_MPENTIUM4) += $(call check_gcc,-march=pentium4,-march=i686)
+cflags-$(CONFIG_MPENTIUMM) += $(call check_gcc,-march=pentium3,-march=i686)
cflags-$(CONFIG_MK6) += $(call check_gcc,-march=k6,-march=i586)
# Please note, that patches that add -march=athlon-xp and friends are pointless.
# They make zero difference whatsosever to performance at this time.
diff -urN a/include/asm-i386/module.h b/include/asm-i386/module.h
--- a/include/asm-i386/module.h 2003-08-23 01:52:22.000000000 +0200
+++ b/include/asm-i386/module.h 2004-01-04 03:08:17.000000000 +0100
@@ -28,6 +28,8 @@
#define MODULE_PROC_FAMILY "PENTIUMIII "
#elif defined CONFIG_MPENTIUM4
#define MODULE_PROC_FAMILY "PENTIUM4 "
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY "PENTIUMM "
#elif defined CONFIG_MK6
#define MODULE_PROC_FAMILY "K6 "
#elif defined CONFIG_MK7
> And since P-M doesn't do SMP, does cache line size even
> matter? There are no locks to protect from ping-ponging.
Cache line size does still come into the picture on UP, albeit not as
much as with SMP - but e.g. it still matters to things like device
drivers doing DMA.
Rob Love
That should probably read "Pentium III/4".
--
Ciaran McCreesh
Mail: ciaranm at gentoo.org
Web: http://dev.gentoo.org/~ciaranm
Regardless, Tomas's patch changed CONFIG_X86_L1_CACHE_SHIFT for
that CPU, and CONFIG_X86_L1_CACHE_SHIFT shouldn't affect this.
The cacheline size is determined at boottime using the code in
pcibios_init() and set using pci_generic_prep_mwi().
The config option is the default that pci_cache_line_size starts at,
but this gets overridden when the CPU type is determined.
Dave
--
Dave Jones http://www.codemonkey.org.uk
> Regardless, Tomas's patch changed CONFIG_X86_L1_CACHE_SHIFT for
> that CPU, and CONFIG_X86_L1_CACHE_SHIFT shouldn't affect this.
> The cacheline size is determined at boottime using the code in
> pcibios_init() and set using pci_generic_prep_mwi().
>
> The config option is the default that pci_cache_line_size starts at,
> but this gets overridden when the CPU type is determined.
Yah. I was just answering in the abstract to the "does cache line
matter on non-SMP" question.
I actually like this patch (perhaps since I have a P-M :) and think it
ought to go in, although I agree with others that the P-M is more of a
super-P3 than a scaled down P4.
Rob Love
> Yah. I was just answering in the abstract to the "does cache line
> matter on non-SMP" question.
>
> I actually like this patch (perhaps since I have a P-M :) and think it
> ought to go in, although I agree with others that the P-M is more of a
> super-P3 than a scaled down P4.
FWIW, I agree with it too on the grounds that its non obvious the optimal
setting is CONFIG_MPENTIUMIII. This seems cleaner IMO than changing the
helptext to read...
"Pentium II"
"Pentium III / Pentium 4M"
"Pentium 4"
My other mail may have sounded like I objected to the patch per se, I don't.
Dave
--
Dave Jones http://www.codemonkey.org.uk
> FWIW, I agree with it too on the grounds that its non obvious the optimal
> setting is CONFIG_MPENTIUMIII. This seems cleaner IMO than changing the
> helptext to read...
>
> "Pentium II"
> "Pentium III / Pentium 4M"
> "Pentium 4"
Oh, very much agreed. Giving it a separate configure option also opens
the door for easily adding an march=pentiumm whenever the gcc folks get
around to adding that.
> My other mail may have sounded like I objected to the patch per se, I don't.
I did not think that, I thought perhaps that you thought that I objected
:)
Rob Love
>FWIW, I agree with it too on the grounds that its non obvious the optimal
>setting is CONFIG_MPENTIUMIII. This seems cleaner IMO than changing the
>helptext to read...
>
> "Pentium II"
> "Pentium III / Pentium 4M"
> "Pentium 4"
>
>
Especially since Pentium M != Pentium 4M :-)
Troels
> On Sun, 2004-01-04 at 11:50, Dave Jones wrote:
>
> > FWIW, I agree with it too on the grounds that its non obvious the optimal
> > setting is CONFIG_MPENTIUMIII. This seems cleaner IMO than changing the
> > helptext to read...
> >
> > "Pentium II"
> > "Pentium III / Pentium 4M"
> > "Pentium 4"
>
> Oh, very much agreed. Giving it a separate configure option also opens
> the door for easily adding an march=pentiumm whenever the gcc folks get
> around to adding that.
Yes. That was the door I was aiming to open. <g>
--
Tomas Szepe <sz...@pinerecords.com>
> >FWIW, I agree with it too on the grounds that its non obvious the optimal
> >setting is CONFIG_MPENTIUMIII. This seems cleaner IMO than changing the
> >helptext to read...
> >
> >"Pentium II"
> >"Pentium III / Pentium 4M"
> >"Pentium 4"
> >
> Especially since Pentium M != Pentium 4M :-)
Indeed. Colour me confused 8-)
Dave
--
Dave Jones http://www.codemonkey.org.uk
> I actually like this patch (perhaps since I have a P-M :) and think it
> ought to go in, although I agree with others that the P-M is more of a
> super-P3 than a scaled down P4.
Same here - /proc/cpuinfo says:
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
Question for those more knowledgeable: Are there any known Pentium4 features
enabled in the kernel with the PENTIUM4 options that simply Will Not Work on a
4M chipset (similar to a kernel built for a 586 not working on a 486), or are
the differences limited to "sub-optimal performance" (for example, compiling
with -mpentium4 results in code that runs but schedules less optimally)? If
there are, they must be fairly obscure corner cases, since I haven't knowingly
hit one in several months.. :)
2.7 timeframe - are there any added features of a P4 core we would *like*
to exploit that aren't on a P4M?
Pentium M and Pentium 4M are two different beasts, by the way.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Pentium 4M is a real Pentium 4 core, but with mobile features.
Pentium M is a beefed up Pentium III core, with mobile features and all
Pentium 4 extra features (instructions, etc).
I think that answers your question.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> Pentium 4M is a real Pentium 4 core, but with mobile features.
>
> Pentium M is a beefed up Pentium III core, with mobile features and all
> Pentium 4 extra features (instructions, etc).
>
> I think that answers your question.
Obviously, I'm confused by more than just the re-used Xeon name, thanks for
the cluestick. :)
Use the same as for P-III.
The P-M has the same instruction decoder (and execution unit) setup as
the P-III, which is *very* different from P-IV (which has one decoder
only, and then a trace cache for the decoded uops). This is an
important difference from a code generator point of view.
From reading Intel's optimization guides, it seems to me like the P-M is
pretty much just a slightly enhanced P-III (more cache AFAIR) which
happens to get shipped with a good mobile chipset - and that package
together is called Centrino.
That would also explain why Centrino leaves the P-IV based laptops in
the dust ;)
Cheers,
/ jakob