On Sun Jul 13 22:20:28 EST 2008, Marvin wrote:
On Saturday 12 July 2008 20:00:05 Arnd Bergmann wrote:
On Saturday 12 July 2008, Marvin wrote:
attached patch introduces a "processor type" menu similar to ppc32.
It _should_ not change anything upto now.
The aim is to allow future fine graded cpu optimizations via
mcpu/mtune compiler flags and also to clean up the arch
Makefile/Kconfig.cputypes (I know this is a minefield).
I tried something similar last year, but failed miserably, because
the complexity cannot really be contained. I still think it's a good
idea, but I'm not sure whether your patch will help at all.
Before I try to change something, I like to get some feedback about
the direction to take. Therefore your comments are more than welcome.
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index f7efaa9..eebde6c 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -54,35 +54,65 @@ config E200
endchoice
-config POWER4_ONLY
- bool "Optimize for POWER4"
+choice
+ prompt "Processor Type"
depends on PPC64
+ default TUNE_POWER4
+ help
+ There are serveral families of 64 bit PowerPC chips
supported.
+ These include the Power3 to Power6 series, 970, and Cell
BE based
+ CPUs made be IBM.
+
+ If unsure, select Power4.
+
+config TUNE_POWER3
+ bool "Power3"
...
+
+config TUNE_CELL
+ bool "Cell Broadband Engine"
+ help
+ Cause the compiler to optimize for the PPE of the Cell
Broadband
+ Engine. This will make the code run considerably faster on
Cell
+ but somewhat slower on other machines. If the resulting
kernel is
+ built to run only on Cell BE machines, select also
OPT_EXCLUSIVE.
+
+endchoice
What about the other CPUs? There is also RS64, Power5+, PA6T and
Power7.
I grepped the source (especially the defconfigs) and it seems, that
there is only one distinction between the different PPC64 archs named
POWER3. POWER4 is always set on PPC64 archs, POWER3 is not set on G5,
maple and pasemi.
Grepping further reveals, that POWER3 is mentioned in mm/pgtable_32.c
only, where is used to define HAVE_BATS (it exists also in
asm/cputable.h, which is a candidate for cleanup -> replace !POWER4 &&
!POWER3 by !PPC64).
My daring conclusion is therefore:
1. POWER3 could be replaced by HAVE_BATS
2. POWER4 could be replaced by PPC64
No, this is the wrong approach. Don't figure out what to call things
by looking at where you see them used. See below for why.
The only processor dependant config left is the tuning option. gcc has
no special option for power7 or pa6t yet, but the reorg should be
flexible, so new tuning options can be added easily. RS64 could be
added to the tuneing options.
Let me give you a hint why you find the current usage.
POWER4 is is the first PowerPC-2.x architecture processor.
POWER3 and the RS64 series implement various versions of the PowerPC
1.x architecture. RS64 decided it didn't need bats.
While for the most part there have only been additions, the biggest
change as far as the operating system is the removal of the BAT and the
replacement of the STAB with the SLB.
That said, there are subtile compatibility problems. There are bits
that are defined in current instructions that should have been ignored
but are not. For example, mtocrf causes a fault on POWER3 but makes
POWER4 and later run mach faster. Also, the encoding of branch
prediction was changed.
POWER4_ONLY says go ahead and compile a kernel that will not run on a
POWER3. However, currently, it still runs on RS64, as we don't
conditionally compile SLB or STAB code.
The reason I said replacing POWER3 to HVAE_BATS is that that is the
wrong interface for the user. The user will know his cpu but will not
know technical things like POWER3 has bats and later ones do not.
That said, I think its perfectly reasonable to have POWER3 select
HAVE_BATS and make the code depend on that FEATURE type config.
+
+config OPT_EXCLUSIVE
+ bool "Optimize to run exclusive on selected CPU"
default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970
processors.
- The resulting binary will not work on POWER3 or RS64
processors
- when compiled with binutils 2.15 or later.
+ help
+ Cause the compiler to optimize to run exclusive on the
selected
+ CPU. The resulting binary will probably not work on other
CPUs.
+
+ If the compiler/binutils combination does not support the
exclusive
+ optimization, it will try to tune only or fail.
+
+ If you are unsure, select no.
Almost all CPUs are backwards compatible, so the option should not be
labelled 'exclusive'. In general, if you build for PowerX, it will
also run on Power(X+1). 970 is backwards compatible to Power4, Cell
and PA6T are backwards compatible to 970, Power6 is backwards
compatible to both of these.
Also, there are good reasons to have the -mcpu option different from
-mtune. E.g. you may want to use Power4 compatible instructions but
tune for Power6 in a typical distro kernel.
ok. That would mean to have two config menus:
- optimize to run exclusive on cpu_x or higher
- tune for cpu_y, and use instruction set for cpu_x, where x<=y
That seems to be rather complex and I think this is also unrealistic,
because there are often only two cases:
- a distro doesn't want to maintain one kernel per cpu. So
they always choose common instructions and tune for some higher cpu
(likely power4).
- a high end user (or specilized distro), who wants to compile
his own kernel for maximum performance compiles exlusive only (e.g.
for cell be).
This is why I choosed "select cpu" menu and a bool for exclusive (use
mcpu) or not (use mtune). Another option would be to add a string
prompt, so the user can enter his own tuning options "-mcpu=cpu_x
-mtune=cpu_y", but I think this is undesired.
config POWER3
- bool
depends on PPC64
- default y if !POWER4_ONLY
+ def_bool y if !POWER4_ONLY
config POWER4
depends on PPC64
def_bool y
-config TUNE_CELL
- bool "Optimize for Cell Broadband Engine"
+config POWER4_ONLY
depends on PPC64
- help
- Cause the compiler to optimize for the PPE of the Cell
Broadband
- Engine. This will make the code run considerably faster on
Cell
- but somewhat slower on other machines. This option only
changes
- the scheduling of instructions, not the selection of
instructions
- itself, so the resulting kernel will keep running on all
other
- machines. When building a kernel that is supposed to run
only
- on Cell, you should also select the POWER4_ONLY option.
+ def_bool y if TUNE_POWER4 && OPT_EXCLUSIVE
config 6xx
bool
Tuning for Cell gives a significant performance bonus on cell based
machines with a new compiler, and again, you would typically want to
use the Power4 instruction set, but not restrict to Power3 or use all
of the Cell instructions.
That's again the "distro/high end user" question discussed above. I
think this was raised several times in the past on this list without a
common conclusion. A small survey shows, that distros are shipping
kernels for ppc32 (sometimes prep and chrp) and ppc64 (common,
iseries, pseries, and ps3) for installation only and provide a single
image for updates. Maybe this would change if there is a choice....
[My appoligies for the late reply, it seems to have gotten left in my
drafts folder. Probably because apple mail did a harrible job wrappig
lines in all the wrong places. I have made all the discussion flow
into paragraphs with what I hope is the proper indenting/attribution.
Perhaps the patch has a singnificant amount of lines with trailing
whitespace?]
milton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
