Since the Pentium M has 64 byte cache lines and is not a K7 or K8... ;)
--
Tomas Szepe <[email protected]>
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
On Sun, 4 Jan 2004 03:28:48 +0100, Tomas Szepe wrote:
>Since the Pentium M has 64 byte cache lines and is not a K7 or K8... ;)
...
>--- 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.
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
On Jan-04 2004, Sun, 13:27 +0100
Mikael Pettersson <[email protected]> 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.
--
Tomas Szepe <[email protected]>
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.
/Mikael
On Jan-04 2004, Sun, 15:10 +0100
Mikael Pettersson <[email protected]> wrote:
> 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 <[email protected]>
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=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
On Sun, 2004-01-04 at 07:27, Mikael Pettersson wrote:
> 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
On Sun, 4 Jan 2004 15:43:50 +0100 Tomas Szepe <[email protected]>
wrote:
| +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
That should probably read "Pentium III/4".
--
Ciaran McCreesh
Mail: ciaranm at gentoo.org
Web: http://dev.gentoo.org/~ciaranm
On Sun, Jan 04, 2004 at 10:03:28AM -0500, Rob Love wrote:
> On Sun, 2004-01-04 at 07:27, Mikael Pettersson wrote:
> > 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.
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
On Sun, 2004-01-04 at 11:25, Dave Jones wrote:
> 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
On Sun, Jan 04, 2004 at 11:33:08AM -0500, Rob Love wrote:
> 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
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"
>
>
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.
> 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
On Jan-04 2004, Sun, 12:01 -0500
Rob Love <[email protected]> wrote:
> 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 <[email protected]>
On Sun, Jan 04, 2004 at 06:03:47PM +0100, Troels Walsted Hansen 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"
> >
> Especially since Pentium M != Pentium 4M :-)
Indeed. Colour me confused 8-)
Dave
--
Dave Jones http://www.codemonkey.org.uk
On Sun, 04 Jan 2004 11:33:08 EST, Rob Love said:
> 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?
On Sun, Jan 04, 2004 at 04:50:28PM +0000, Dave Jones wrote:
> On Sun, Jan 04, 2004 at 11:33:08AM -0500, Rob Love wrote:
>
> > 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.
Pentium M and Pentium 4M are two different beasts, by the way.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Jan 04, 2004 at 03:34:47PM -0500, [email protected] wrote:
> On Sun, 04 Jan 2004 11:33:08 EST, Rob Love said:
>
> > 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 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
On Sun, 04 Jan 2004 22:55:41 +0100, Vojtech Pavlik said:
> 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. :)
: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.
:
:/Mikael
Perhaps -mcpu=pentium3 -march=pentium4 would be a good compromise? From the
GCC 3.3 info pages:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. [...]
While picking a specific CPU-TYPE will schedule things
appropriately for that particular chip, the compiler will not
generate any code that does not run on the i386 without the
`-march=CPU-TYPE' option being used. [...]
`-march=CPU-TYPE'
Generate instructions for the machine type CPU-TYPE. The choices
for CPU-TYPE are the same as for `-mcpu'. Moreover, specifying
`-march=CPU-TYPE' implies `-mcpu=CPU-TYPE'.
Amit
On Mon, 5 Jan 2004, Amit Gurdasani wrote:
> Perhaps -mcpu=pentium3 -march=pentium4 would be a good compromise? From the
> GCC 3.3 info pages:
[...]
> for CPU-TYPE are the same as for `-mcpu'. Moreover, specifying
> `-march=CPU-TYPE' implies `-mcpu=CPU-TYPE'.
... thus leaving the "-mcpu=pentium3" without effect.
Tim
On Sun, Jan 04, 2004 at 01:33:58PM +0100, Tomas Szepe wrote:
> On Jan-04 2004, Sun, 13:27 +0100
> Mikael Pettersson <[email protected]> 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.
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
On Sun, Jan 04, 2004 at 01:33:58PM +0100, Tomas Szepe wrote:
> On Jan-04 2004, Sun, 13:27 +0100
> Mikael Pettersson <[email protected]> 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.
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
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.
/Mikael
On Sun, 2004-01-04 at 11:25, Dave Jones wrote:
> 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
On Sun, Jan 04, 2004 at 11:33:08AM -0500, Rob Love wrote:
> 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
On Jan-04 2004, Sun, 15:10 +0100
Mikael Pettersson <[email protected]> wrote:
> 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 <[email protected]>
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=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
On Jan-04 2004, Sun, 13:27 +0100
Mikael Pettersson <[email protected]> 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.
--
Tomas Szepe <[email protected]>
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.
> 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
On Sun, 4 Jan 2004 03:28:48 +0100, Tomas Szepe wrote:
>Since the Pentium M has 64 byte cache lines and is not a K7 or K8... ;)
...
>--- 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.
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
On Jan-04 2004, Sun, 12:01 -0500
Rob Love <[email protected]> wrote:
> 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 <[email protected]>
On Sun, 4 Jan 2004 15:43:50 +0100 Tomas Szepe <[email protected]>
wrote:
| +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
That should probably read "Pentium III/4".
--
Ciaran McCreesh
Mail: ciaranm at gentoo.org
Web: http://dev.gentoo.org/~ciaranm
On Sun, 2004-01-04 at 07:27, Mikael Pettersson wrote:
> 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
On Sun, Jan 04, 2004 at 10:03:28AM -0500, Rob Love wrote:
> On Sun, 2004-01-04 at 07:27, Mikael Pettersson wrote:
> > 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.
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