2.6.1-rc1-tiny2

This is the fourth release of the -tiny kernel tree. The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.

Latest release includes:
- various compile fixes for last release
- actually include Andi Kleen's bloat-o-meter this time
- optional mempool removal
- optional semaphore uninlining
- optional linux socket filter
- reduced flow cache
- optional device multicast management
- optional rtnetlink/af_netlink
- optional IGMP
- optional POSIX timer API
- inline cleanup in fs/namei.c

The patch can be found at:

http://selenic.com/tiny/2.6.1-rc1-tiny2.patch.bz2
http://selenic.com/tiny/2.6.1-rc1-tiny2-broken-out.tar.bz2

Webpage for your bookmarking pleasure:

http://selenic.com/tiny-about/

Matt Mackall : http://www.selenic.com : Linux development and consulting

Have you considered Adrian Bunk's CPU selection rationalisation work? The last argument I heard against it was that there is lower hanging fruit for size reduction. You seem to have got a lot of that.

Nick

Vaguely aware of it.

Yes, a fair amount. Btw, what's the size differential for piggin-sched vs mainline?

Matt Mackall : http://www.selenic.com : Linux development and consulting

Basically, because the types of x86 cpus are only partially ordered, and a the CPU selection somehow tries to follow the rule "this CPU or higher", there ends up being a bit of stuff included which doesn't need to be. Not sure what the savings add up to though...

Very little, I think my sched.o is about 40 bytes bigger on UP. Its about 4K bigger for SMP, but thats with quite a bit of init stuff to set up the sched domains. It also does HT scheduling, and some more of that could be ifdefed I guess (its already 1-2K smaller than Ingo's shared runqueues).

If you're talking about my interactivity stuff, then that is very little difference as well, maybe a few tens of bytes smaller. The scheduler is pretty lean.

Some savings are possible as a side effect of my patch (the main goal is to make the selection of multiple CPUs more user friendly).

I'll send the patch and 2 proof of concept space saving patches as replies to this mail.

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

The patches below are:

[1/4]
- changed the i386 CPU selection from a choice to single options for every cpu
- renamed the M* variables to CPU_*, this is needed to ask the users upgrading from older kernels instead of silently changing the semantics
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- help text changes/updates

[2/4]
move "struct movsl_mask movsl_mask" to usercopy.c (CONFIG_X86_INTEL_USERCOPY is used on non-Intel CPUs)

[3/4]
- made arch/i386/kernel/cpu/Makefile CPU specific

[4/4]
- made arch/i386/kernel/cpu/mtrr/Makefile CPU specific

Dependencies between these patches:
- patch 3 requires 1+2
- patch 4 requires 1

The main part is patch 1.

Patch 2 fixes a small issue that only shows up with patch 3.

Patches 3+4 are proof of concept patches for space optimizations by omitting unneeded code. They are "proof of concept" since the #ifdef's they introduce aren't

TODO:
- change include/asm-i386/module.h to use some kind of bitmask

I've updated the patches for 2.6.1-rc3 and a kernel with these patches applied compiles and runs for me.

cu
Adrian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Changes:

- changed the i386 CPU selection from a choice to single options for every cpu
- X86_GENERIC is no longer required
- renamed the M* variables to CPU_*, this is needed to ask the users upgrading from older kernels instead of silently changing the semantics
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- help text changes/updates

TODO:
- module versioning

diffstat output:

 arch/i386/Kconfig                    |  258 ++++++++++++---------------
 arch/i386/Makefile                   |   57 +++--
 arch/i386/boot/setup.S               |    2 
 arch/i386/lib/mmx.c                  |    2 
 drivers/serial/8250.h                |    2 
 include/asm-i386/apic.h              |    4 
 include/asm-i386/bugs.h              |    7 
 include/asm-i386/module.h            |    2 
 include/asm-i386/processor.h         |    4 
 include/asm-i386/timex.h             |    2 
 arch/x86_64/Kconfig                  |    4 
 include/asm-x86_64/apic.h            |    2 
 arch/i386/kernel/cpu/cpufreq/Kconfig |    2 
 arch/i386/mach-voyager/voyager_smp.c |    6 
 14 files changed, 172 insertions(+), 182 deletions(-)

@@ -43,6 +43,15 @@
 	help
 	  Choose this option if your computer is a standard PC or compatible.
 
+config X86_ELAN
+	bool "Elan"
+	help
+	  Select this for an AMD Elan processor.
+	
+	  Do not use this option for K6/Athlon/Opteron processors!
+	
+	  If unsure choose "PC-compatible" instead.
+
 config X86_VOYAGER
 	bool "Voyager (NCR)"
 	help

@@ -125,48 +134,19 @@
 	default y
 	depends on SMP && X86_ES7000 && MPENTIUMIII
 
-choice
-	prompt "Processor family"
-	default M686
 
-config M386
-	bool "386"
-	---help---
-	  This is the processor type of your CPU. This information is used for
-	  optimizing purposes. In order to compile a kernel that can run on
-	  all x86 CPU types (albeit not optimally fast), you can specify
-	  "386" here.
-
-	  The kernel will not necessarily run on earlier architectures than
-	  the one you have chosen, e.g. a Pentium optimized kernel will run on
-	  a PPro, but not necessarily on a i486.
-
-	  Here are the settings recommended for greatest speed:
-	  - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
-	  486DLC/DLC2, UMC 486SX-S and NexGen Nx586.  Only "386" kernels
-	  will run on a 386 class machine.
-	  - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
-	  SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
-	  - "586" for generic Pentium CPUs lacking the TSC
-	  (time stamp counter) register.
-	  - "Pentium-Classic" for the Intel Pentium.
-	  - "Pentium-MMX" for the Intel Pentium MMX.
-	  - "Pentium-Pro" for the Intel Pentium Pro.
-	  - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
-	  - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
-	  - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
-	  - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
-	  - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
-	  - "Crusoe" for the Transmeta Crusoe series.
-	  - "Winchip-C6" for original IDT Winchip.
-	  - "Winchip-2" for IDT Winchip 2.
-	  - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
-	  - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
-	  - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
+
+menu "Processor support"
+
+comment "Select all processors your kernel should support"
 
-	  If you don't know what to do, choose "386".
+config CPU_386
+	bool "386"
+	help
+	  Select this for a 386 series processor.
 
-config M486
+config CPU_486
 	bool "486"
 	help
 	  Select this for a 486 series processor, either Intel or one of the

@@ -174,227 +154,223 @@
 	  DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
 	  U5S.
 
-config M586
+config CPU_586
 	bool "586/K5/5x86/6x86/6x86MX"
 	help
-	  Select this for an 586 or 686 series processor such as the AMD K5,
-	  the Intel 5x86 or 6x86, or the Intel 6x86MX.  This choice does not
-	  assume the RDTSC (Read Time Stamp Counter) instruction.
+	  Select this for a non-Intel 586 or 686 series processor such as
+	  the AMD K5 or the Cyrix 6x86MX.
+	
+	  Several CPUs that have their own options below (e.g. AMD K6,
+	  Duron, Athlon and Opteeron, IDT Winchip, Cyrix III and
+	  VIA C3) do _not_ need this option.
+	
+	  This choice does not assume the RDTSC (Read Time Stamp Counter)
+	  instruction.
 
-config M586TSC
+config CPU_586TSC
 	bool "Pentium-Classic"
 	help
 	  Select this for a Pentium Classic processor with the RDTSC (Read
-	  Time Stamp Counter) instruction for benchmarking.
+	  Time Stamp Counter) instruction.
 
-config M586MMX
+config CPU_586MMX
 	bool "Pentium-MMX"
 	help
 	  Select this for a Pentium with the MMX graphics/multimedia
 	  extended instructions.
 
-config M686
+config CPU_686
 	bool "Pentium-Pro"
 	help
-	  Select this for Intel Pentium Pro chips.  This enables the use of
-	  Pentium Pro extended instructions, and disables the init-time guard
-	  against the f00f bug found in earlier Pentiums.
+	  Select this for Intel Pentium Pro chips.
 
-config MPENTIUMII
+config CPU_PENTIUMII
 	bool "Pentium-II/Celeron(pre-Coppermine)"
 	help
 	  Select this for Intel chips based on the Pentium-II and
-	  pre-Coppermine Celeron core.  This option enables an unaligned
-	  copy optimization, compiles the kernel with optimization flags
-	  tailored for the chip, and applies any applicable Pentium Pro
-	  optimizations.
+	  pre-Coppermine Celeron core.
 
-config MPENTIUMIII
+config CPU_PENTIUMIII
 	bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
 	help
 	  Select this for Intel chips based on the Pentium-III and
-	  Celeron-Coppermine core.  This option enables use of some
-	  extended prefetch instructions in addition to the Pentium II
-	  extensions.
+	  Celeron-Coppermine core.
 
-config MPENTIUM4
+config CPU_PENTIUM4
 	bool "Pentium-4/Celeron(P4-based)/Xeon"
 	help
 	  Select this for Intel Pentium 4 chips.  This includes both
-	  the Pentium 4 and P4-based Celeron chips.  This option
-	  enables compile flags optimized for the chip, uses the
-	  correct cache shift, and applies any applicable Pentium III
-	  optimizations.
+	  the Pentium 4 and P4-based Celeron chips.
 
-config MK6
+config CPU_K6
 	bool "K6/K6-II/K6-III"
 	help
-	  Select this for an AMD K6-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
 
-config MK7
+config CPU_K7
 	bool "Athlon/Duron/K7"
 	help
-	  Select this for an AMD Athlon K7-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD Athlon K7-family processor.
 
-config MK8
+config CPU_K8
 	bool "Opteron/Athlon64/Hammer/K8"
 	help
-	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.  Enables
-	  use of some extended instructions, and passes appropriate optimization
-	  flags to GCC.
-
-config MELAN
-	bool "Elan"
+	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.
 
-config MCRUSOE
+config CPU_CRUSOE
 	bool "Crusoe"
 	help
-	  Select this for a Transmeta Crusoe processor.  Treats the processor
-	  like a 586 with TSC, and sets some GCC optimization flags (like a
-	  Pentium Pro with no alignment requirements).
+	  Select this for a Transmeta Crusoe processor.
 
-config MWINCHIPC6
+config CPU_WINCHIPC6
 	bool "Winchip-C6"
 	help
-	  Select this for an IDT Winchip C6 chip.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip C6 chip.
 
-config MWINCHIP2
+config CPU_WINCHIP2
 	bool "Winchip-2"
 	help
-	  Select this for an IDT Winchip-2.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip-2.
 
-config MWINCHIP3D
+config CPU_WINCHIP3D
 	bool "Winchip-2A/Winchip-3"
 	help
-	  Select this for an IDT Winchip-2A or 3.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment reqirements.  Also enable out of order memory
-	  stores for this CPU, which can increase performance of some
-	  operations.
-
-config MCYRIXIII
-	bool "CyrixIII/VIA-C3"
-	help
-	  Select this for a Cyrix III or C3 chip.  Presently Linux and GCC
-	  treat this chip as a generic 586. Whilst the CPU is 686 class,
-	  it lacks the cmov extension which gcc assumes is present when
-	  generating 686 code.
-	  Note that Nehemiah (Model 9) and above will not boot with this
-	  kernel due to them lacking the 3DNow! instructions used in earlier
-	  incarnations of the CPU.
+	  Select this for an IDT Winchip-2A or 3 with 3dNow!
+	  capabilities.
+
+config CPU_CYRIXIII
+	bool "Cyrix III/VIA C3"
+	help
+	  Select this for a Cyrix III or VIA C3 chip.
 
-config MVIAC3_2
+	  Note that Nehemiah (Model 9) and above need the next
+	  option instead.
+
+config CPU_VIAC3_2
 	bool "VIA C3-2 (Nehemiah)"
 	help
-	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
-	  of SSE and tells gcc to treat the CPU as a 686.
-	  Note, this kernel will not boot on older (pre model 9) C3s.
+	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
 
-endchoice
+endmenu
 
-config X86_GENERIC
-       bool "Generic x86 support" 
-       help
-       	  Including some tuning for non selected x86 CPUs too.
-	  when it has moderate overhead. This is intended for generic 
-	  distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_INTEL
+	bool
+	depends on CPU_386 || CPU_486 || CPU_586TSC || CPU_686 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUM4
+	default y
+
+config CPU_WINCHIP
+	bool
+	depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+	default y
+
+config CPU_ONLY_K7
+	bool
+	depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+	default y
+
+config CPU_ONLY_K8
+	bool
+	depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+	default y
+
+config CPU_ONLY_WINCHIP
+	bool
+	depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+	default y
 
 #
 # Define implied options from the CPU selection here
 #
 config X86_CMPXCHG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_XADD
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_L1_CACHE_SHIFT
 	int
-	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 "7" if CPU_PENTIUM4
+	default "6" if CPU_K7 || CPU_K8
+	default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+	default "4" if X86_ELAN || CPU_486 || CPU_386
 
 config RWSEM_GENERIC_SPINLOCK
 	bool
-	depends on M386
+	depends on CPU_386
 	default y
 
 config RWSEM_XCHGADD_ALGORITHM
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_PPRO_FENCE
 	bool
-	depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_686
 	default y
 
 config X86_F00F_BUG
 	bool
-	depends on M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_586MMX || CPU_586TSC
 	default y
 
 config X86_WP_WORKS_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_INVLPG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_BSWAP
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_POPAD_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_ALIGNMENT_16
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+	depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
 	default y
 
-config X86_GOOD_APIC
+config X86_BAD_APIC
 	bool
-	depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+	depends on CPU_586TSC
 	default y
 
 config X86_INTEL_USERCOPY
 	bool
-	depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+	depends on CPU_K7 || CPU_K8 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUM4
 	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 !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
 	default y
 
 config X86_USE_3DNOW
 	bool
-	depends on MCYRIXIII || MK7
+	depends on !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
 	default y
 
 config X86_OOSTORE
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+	depends on CPU_ONLY_WINCHIP
 	default y
 
 config X86_4G

@@ -555,7 +531,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 !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
 	default y
 
 config X86_MCE

@@ -555,7 +555,7 @@
 #define K7_NOP7        ".byte 0x8D,0x04,0x05,0,0,0,0\n"
 #define K7_NOP8        K7_NOP7 ASM_NOP1
 
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
 #define ASM_NOP1 K8_NOP1
 #define ASM_NOP2 K8_NOP2
 #define ASM_NOP3 K8_NOP3

@@ -564,7 +564,7 @@
 #define ASM_NOP6 K8_NOP6
 #define ASM_NOP7 K8_NOP7
 #define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
 #define ASM_NOP1 K7_NOP1
 #define ASM_NOP2 K7_NOP2
 #define ASM_NOP3 K7_NOP3

@@ -44,7 +44,7 @@
 
 #undef SERIAL_DEBUG_PCI
 
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
 #define SERIAL_INLINE
 #endif
   

@@ -755,7 +755,7 @@
 # AMD Elan bug fix by Robert Schwebel.
 #
 
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
 	movb $0x02, %al			# alternate A20 gate
 	outb %al, $0x92			# this works on SC410/SC520
 a20_elan_wait:

@@ -12,7 +12,7 @@
 #ifdef CONFIG_X86_PC9800
    extern int CLOCK_TICK_RATE;
 #else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
 #  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
 #else
 #  define CLOCK_TICK_RATE 1193182 /* Underlying HZ */

@@ -121,7 +121,7 @@
 	return p;
 }
 
-#ifdef CONFIG_MK7
+#ifdef CONFIG_CPU_ONLY_K7
 
 /*
  *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and

@@ -165,9 +165,8 @@
  * - In order to run on anything without a TSC, we need to be
  *   compiled for a i486.
  * - In order to support the local APIC on a buggy Pentium machine,
- *   we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- *   which happens implicitly if compiled for a Pentium or lower
- *   (unless an advanced selection of CPU features is used) as an
+ *   we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ *   which happens implicitly if compiled for a Pentium as an
  *   otherwise config implies a properly working local APIC without
  *   the need to do extra reads from the APIC.
 */

@@ -198,7 +197,7 @@
  * integrated APIC (see 11AP erratum in "Pentium Processor
  * Specification Update").
  */
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
 	    && cpu_has_apic
 	    && boot_cpu_data.x86 == 5

@@ -49,7 +49,7 @@
 #elif CONFIG_MVIAC3_2
 #define MODULE_PROC_FAMILY "VIAC3-2 "
 #else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
 #endif
 
 #define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY

@@ -41,7 +41,7 @@
 	do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
 }
 
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
 # define FORCE_READ_AROUND_WRITE 0
 # define apic_read_around(x)
 # define apic_write_around(x,y) apic_write((x),(y))

@@ -56,7 +56,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

@@ -553,7 +553,7 @@
 
 	/* For the 486, we can't use the 4Mb page table trick, so
 	 * must map a region of memory */
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	int i;
 	unsigned long *page_table_copies = (unsigned long *)
 		__get_free_page(GFP_KERNEL);

@@ -612,7 +612,7 @@
 	/* set the original swapper_pg_dir[0] to map 0 to 4Mb transparently
 	 * (so that the booting CPU can find start_32 */
 	orig_swapper_pg_dir0 = swapper_pg_dir[0];
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	if(page_table_copies == NULL)
 		panic("No free memory for 486 page tables\n");
 	for(i = 0; i < PAGE_SIZE/sizeof(unsigned long); i++)

@@ -669,7 +669,7 @@
 	/* reset the page table */
 	swapper_pg_dir[0] = orig_swapper_pg_dir0;
 	local_flush_tlb();
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	free_page((unsigned long)page_table_copies);
 #endif
 	  

@@ -54,7 +54,7 @@
 
 config ELAN_CPUFREQ
 	tristate "AMD Elan"
-	depends on CPU_FREQ_TABLE && MELAN
+	depends on CPU_FREQ_TABLE && X86_ELAN
 	---help---
 	  This adds the CPUFreq driver for AMD Elan SC400 and SC410
 	  processors.

@@ -108,10 +108,6 @@
 	bool
 	default y
 
-config X86_GOOD_APIC
-	bool
-	default y
-
 config X86_MSR
 	tristate "/dev/cpu/*/msr - Model-specific register support"
 	help

@@ -52,7 +52,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

There was another patch last week which added a seperate option for Centrino CPUs, perhaps you can fold that into this patch? The current situation is quite confusing since none of the CPU choices mention Centrine.

Wichert.

Wichert Akkerman <[email protected]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Thanks for this suggestion. An updated version of this patch is below.

cu
Adrian

Changes:

- changed the i386 CPU selection from a choice to single options for every cpu
- X86_GENERIC is no longer required
- renamed the M* variables to CPU_*, this is needed to ask the users upgrading from older kernels instead of silently changing the semantics
- added Pentium M and Pentium-4 M
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- help text changes/updates

TODO:
- module versioning

diffstat output:

 arch/i386/Kconfig                    |  273 ++++++++++++---------------
 arch/i386/Makefile                   |   58 +++--
 arch/i386/boot/setup.S               |    2 
 arch/i386/kernel/cpu/cpufreq/Kconfig |    2 
 arch/i386/lib/mmx.c                  |    2 
 arch/i386/mach-voyager/voyager_smp.c |    6 
 arch/x86_64/Kconfig                  |    4 
 drivers/serial/8250.h                |    2 
 include/asm-i386/apic.h              |    4 
 include/asm-i386/bugs.h              |    7 
 include/asm-i386/module.h            |    4 
 include/asm-i386/processor.h         |    4 
 include/asm-i386/timex.h             |    2 
 include/asm-x86_64/apic.h            |    2 
 14 files changed, 186 insertions(+), 186 deletions(-)

@@ -555,7 +555,7 @@
 #define K7_NOP7        ".byte 0x8D,0x04,0x05,0,0,0,0\n"
 #define K7_NOP8        K7_NOP7 ASM_NOP1
 
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
 #define ASM_NOP1 K8_NOP1
 #define ASM_NOP2 K8_NOP2
 #define ASM_NOP3 K8_NOP3

@@ -564,7 +564,7 @@
 #define ASM_NOP6 K8_NOP6
 #define ASM_NOP7 K8_NOP7
 #define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
 #define ASM_NOP1 K7_NOP1
 #define ASM_NOP2 K7_NOP2
 #define ASM_NOP3 K7_NOP3

@@ -44,7 +44,7 @@
 
 #undef SERIAL_DEBUG_PCI
 
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
 #define SERIAL_INLINE
 #endif
   

@@ -755,7 +755,7 @@
 # AMD Elan bug fix by Robert Schwebel.
 #
 
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
 	movb $0x02, %al			# alternate A20 gate
 	outb %al, $0x92			# this works on SC410/SC520
 a20_elan_wait:

@@ -12,7 +12,7 @@
 #ifdef CONFIG_X86_PC9800
    extern int CLOCK_TICK_RATE;
 #else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
 #  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
 #else
 #  define CLOCK_TICK_RATE 1193182 /* Underlying HZ */

@@ -121,7 +121,7 @@
 	return p;
 }
 
-#ifdef CONFIG_MK7
+#ifdef CONFIG_CPU_ONLY_K7
 
 /*
  *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and

@@ -165,9 +165,8 @@
  * - In order to run on anything without a TSC, we need to be
  *   compiled for a i486.
  * - In order to support the local APIC on a buggy Pentium machine,
- *   we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- *   which happens implicitly if compiled for a Pentium or lower
- *   (unless an advanced selection of CPU features is used) as an
+ *   we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ *   which happens implicitly if compiled for a Pentium as an
  *   otherwise config implies a properly working local APIC without
  *   the need to do extra reads from the APIC.
 */

@@ -198,7 +197,7 @@
  * integrated APIC (see 11AP erratum in "Pentium Processor
  * Specification Update").
  */
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
 	    && cpu_has_apic
 	    && boot_cpu_data.x86 == 5

@@ -41,7 +41,7 @@
 	do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
 }
 
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
 # define FORCE_READ_AROUND_WRITE 0
 # define apic_read_around(x)
 # define apic_write_around(x,y) apic_write((x),(y))

@@ -56,7 +56,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

@@ -553,7 +553,7 @@
 
 	/* For the 486, we can't use the 4Mb page table trick, so
 	 * must map a region of memory */
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	int i;
 	unsigned long *page_table_copies = (unsigned long *)
 		__get_free_page(GFP_KERNEL);

@@ -612,7 +612,7 @@
 	/* set the original swapper_pg_dir[0] to map 0 to 4Mb transparently
 	 * (so that the booting CPU can find start_32 */
 	orig_swapper_pg_dir0 = swapper_pg_dir[0];
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	if(page_table_copies == NULL)
 		panic("No free memory for 486 page tables\n");
 	for(i = 0; i < PAGE_SIZE/sizeof(unsigned long); i++)

@@ -669,7 +669,7 @@
 	/* reset the page table */
 	swapper_pg_dir[0] = orig_swapper_pg_dir0;
 	local_flush_tlb();
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	free_page((unsigned long)page_table_copies);
 #endif
 	  

@@ -54,7 +54,7 @@
 
 config ELAN_CPUFREQ
 	tristate "AMD Elan"
-	depends on CPU_FREQ_TABLE && MELAN
+	depends on CPU_FREQ_TABLE && X86_ELAN
 	---help---
 	  This adds the CPUFreq driver for AMD Elan SC400 and SC410
 	  processors.

@@ -108,10 +108,6 @@
 	bool
 	default y
 
-config X86_GOOD_APIC
-	bool
-	default y
-
 config X86_MSR
 	tristate "/dev/cpu/*/msr - Model-specific register support"
 	help

@@ -52,7 +52,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

@@ -26,6 +26,8 @@
 #define MODULE_PROC_FAMILY "PENTIUMII "
 #elif defined CONFIG_MPENTIUMIII
 #define MODULE_PROC_FAMILY "PENTIUMIII "
+#elif defined CONFIG_MPENTIUMM
+#define MODULE_PROC_FAMILY "PENTIUMM "
 #elif defined CONFIG_MPENTIUM4
 #define MODULE_PROC_FAMILY "PENTIUM4 "
 #elif defined CONFIG_MK6

@@ -49,7 +51,7 @@
 #elif CONFIG_MVIAC3_2
 #define MODULE_PROC_FAMILY "VIAC3-2 "
 #else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
 #endif
 
 #define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY

Below is the patch against -mm3 (-mm3 already contains some small patches that were formerly included in ths patch).

@Andrew:

Could you include it in one -mm patch to give it a bit more testing?

This patch changes the way the CPUs are selected from the current "select a reasonable setting that supports all your CPUs, and for further optimizations for more than one CPU type you might also want to enable X86_GENERIC" to "select all CPUs your kernel should support" which is a better understandable semantics for users (= people configuring a kernel).

As a side effect, further optimizations are possible based on this patch, but they are _not_ included.

Changes:

- changed the i386 CPU selection from a choice to single options for every cpu
- X86_GENERIC is no longer required
- renamed the M* variables to CPU_*, this is needed to ask the users upgrading from older kernels instead of silently changing the semantics
- X86_GOOD_APIC -> X86_BAD_APIC
- help text changes/updates

TODO:
- module versioning

diffstat output:

 arch/i386/Kconfig                    |  251 +++++++++++----------------
 arch/i386/Makefile                   |   59 ++++--
 arch/i386/lib/mmx.c                  |    2 
 arch/i386/mach-voyager/voyager_smp.c |    6 
 arch/x86_64/Kconfig                  |    4 
 drivers/serial/8250.h                |    2 
 include/asm-i386/apic.h              |    4 
 include/asm-i386/bugs.h              |    7 
 include/asm-i386/module.h            |    2 
 include/asm-i386/processor.h         |    4 
 include/asm-x86_64/apic.h            |    2 
 11 files changed, 159 insertions(+), 184 deletions(-)

@@ -555,7 +555,7 @@
 #define K7_NOP7        ".byte 0x8D,0x04,0x05,0,0,0,0\n"
 #define K7_NOP8        K7_NOP7 ASM_NOP1
 
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
 #define ASM_NOP1 K8_NOP1
 #define ASM_NOP2 K8_NOP2
 #define ASM_NOP3 K8_NOP3

@@ -564,7 +564,7 @@
 #define ASM_NOP6 K8_NOP6
 #define ASM_NOP7 K8_NOP7
 #define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
 #define ASM_NOP1 K7_NOP1
 #define ASM_NOP2 K7_NOP2
 #define ASM_NOP3 K7_NOP3

@@ -44,7 +44,7 @@
 
 #undef SERIAL_DEBUG_PCI
 
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
 #define SERIAL_INLINE
 #endif
   

@@ -121,7 +121,7 @@
 	return p;
 }
 
-#ifdef CONFIG_MK7
+#ifdef CONFIG_CPU_ONLY_K7
 
 /*
  *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and

@@ -165,9 +165,8 @@
  * - In order to run on anything without a TSC, we need to be
  *   compiled for a i486.
  * - In order to support the local APIC on a buggy Pentium machine,
- *   we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- *   which happens implicitly if compiled for a Pentium or lower
- *   (unless an advanced selection of CPU features is used) as an
+ *   we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ *   which happens implicitly if compiled for a Pentium as an
  *   otherwise config implies a properly working local APIC without
  *   the need to do extra reads from the APIC.
 */

@@ -198,7 +197,7 @@
  * integrated APIC (see 11AP erratum in "Pentium Processor
  * Specification Update").
  */
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
 	    && cpu_has_apic
 	    && boot_cpu_data.x86 == 5

@@ -41,7 +41,7 @@
 	do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
 }
 
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
 # define FORCE_READ_AROUND_WRITE 0
 # define apic_read_around(x)
 # define apic_write_around(x,y) apic_write((x),(y))

@@ -56,7 +56,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

@@ -553,7 +553,7 @@
 
 	/* For the 486, we can't use the 4Mb page table trick, so
 	 * must map a region of memory */
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	int i;
 	unsigned long *page_table_copies = (unsigned long *)
 		__get_free_page(GFP_KERNEL);

@@ -612,7 +612,7 @@
 	/* set the original swapper_pg_dir[0] to map 0 to 4Mb transparently
 	 * (so that the booting CPU can find start_32 */
 	orig_swapper_pg_dir0 = swapper_pg_dir[0];
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	if(page_table_copies == NULL)
 		panic("No free memory for 486 page tables\n");
 	for(i = 0; i < PAGE_SIZE/sizeof(unsigned long); i++)

@@ -669,7 +669,7 @@
 	/* reset the page table */
 	swapper_pg_dir[0] = orig_swapper_pg_dir0;
 	local_flush_tlb();
-#ifdef CONFIG_M486
+#ifdef CONFIG_CPU_486
 	free_page((unsigned long)page_table_copies);
 #endif
 	  

@@ -108,10 +108,6 @@
 	bool
 	default y
 
-config X86_GOOD_APIC
-	bool
-	default y
-
 config X86_MSR
 	tristate "/dev/cpu/*/msr - Model-specific register support"
 	help

@@ -52,7 +52,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 

@@ -49,7 +51,7 @@
 #elif CONFIG_MVIAC3_2
 #define MODULE_PROC_FAMILY "VIAC3-2 "
 #else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
 #endif
 
 #define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY

It would be good to also update arch/i386/defconfig, as the current breaks our auto-compile, which uses 'make defconfig' This patch sets a default CPU also.

Patch
-------------------------------

diff -Nur a/arch/i386/defconfig b/arch/i386/defconfig
@@ -48,26 +48,36 @@
 # CONFIG_X86_VISWS is not set
 # CONFIG_X86_GENERICARCH is not set
 # CONFIG_X86_ES7000 is not set
-# CONFIG_M386 is not set
-# CONFIG_M486 is not set
-# CONFIG_M586 is not set
-# CONFIG_M586TSC is not set
-# CONFIG_M586MMX is not set
-# CONFIG_M686 is not set
-# CONFIG_MPENTIUMII is not set
-# CONFIG_MPENTIUMIII is not set
-CONFIG_MPENTIUM4=y
-# CONFIG_MK6 is not set
-# CONFIG_MK7 is not set
-# CONFIG_MK8 is not set
-# CONFIG_MELAN is not set
-# CONFIG_MCRUSOE is not set
-# CONFIG_MWINCHIPC6 is not set
-# CONFIG_MWINCHIP2 is not set
-# CONFIG_MWINCHIP3D is not set
-# CONFIG_MCYRIXIII is not set
-# CONFIG_MVIAC3_2 is not set
-# CONFIG_X86_GENERIC is not set
+
+#
+
+#
+# Processor support
+#
+
+#
+# Select all processors your kernel should support
+#
+# CONFIG_CPU_386 is not set
+# CONFIG_CPU_486 is not set
+# CONFIG_CPU_586 is not set
+# CONFIG_CPU_586TSC is not set
+# CONFIG_CPU_586MMX is not set
+# CONFIG_CPU_686 is not set
+# CONFIG_CPU_PENTIUMII is not set
+# CONFIG_CPU_PENTIUMIII is not set
+# CONFIG_CPU_PENTIUMM is not set
+CONFIG_CPU_PENTIUM4=y
+# CONFIG_CPU_K6 is not set
+# CONFIG_CPU_K7 is not set
+# CONFIG_CPU_K8 is not set
+# CONFIG_CPU_CRUSOE is not set
+# CONFIG_CPU_WINCHIPC6 is not set
+# CONFIG_CPU_WINCHIP2 is not set
+# CONFIG_CPU_WINCHIP3D is not set
+# CONFIG_CPU_CYRIXIII is not set
+# CONFIG_CPU_VIAC3_2 is not set
+CONFIG_CPU_INTEL=y
 CONFIG_X86_CMPXCHG=y
 CONFIG_X86_XADD=y
 CONFIG_X86_L1_CACHE_SHIFT=7

-----------------------
cliffw
OSDL

NO! NO! This prevents development of an AMD embeded system on an "ordinary" machine like this one (Pentium IV). The fact that the timer runs at a different speed means nothing, one just sets the workstation time every day. Please do NOT do this. It prevents important usage.

There are no such different "optimizations" for ELAN.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

Can't you just configure it for some lower denominator such as 386?

I must say that I'm a bit wobbly about Adrian's recent patches, simply because of the overall intrusiveness and conceptual changes which they introduce.

Remind me again, what did they buy us?

The only patch where I'd say this really applies to is better-i386-cpu-selection.patch .

I'm really happy that you added it in the latest -mm and I'm even more happy that I haven't yet heard of any major breakage it has caused.

But it's your decision whether you like this patch or prefer to drop it.

The main effect is that better-i386-cpu-selection.patch makes it easier for people who configure kernels that should work on different CPU types. A user (= person compiling his own kernel) does no longer need any deeper knowledge when e.g. configuring a kernel that should run on both an Athlon and a Pentium 4 - he simply selects all CPUs he wants to support in his kernel.

As a side effect, this patch allows further optimizations based on the fact that e.g. a kernel for an i386 no longer needs to support an Athlon which can be used to omit support for non-selected CPUs [1].

cu
Adrian

[1] e.g. there's no need to include arch/i386/kernel/cpu/amd.c in your kernel if the kernel should only run on a 386;
I made two such example patches that are _way_ too ugly for merging but show that this CPU selection scheme makes some more space savings possible

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Adrian> The main effect is that better-i386-cpu-selection.patch makes Adrian> it easier for people who configure kernels that should work on Adrian> different CPU types. A user (= person compiling his own Adrian> kernel) does no longer need any deeper knowledge when Adrian> e.g. configuring a kernel that should run on both an Athlon Adrian> and a Pentium 4 - he simply selects all CPUs he wants to Adrian> support in his kernel.

So a user who will only Run this kernel on a PIII for example, doesn't need to select *any* other kernels at all? I think the Kconfig help screens need to be redone to make this clear.

I enabled all the sub-processors because I wanted to make sure my kernel would boot no matter what. It seems like I don't need that any more, right?

John

At the top of the "Processor support" menu there is the line "Select all processors your kernel should support". That sums it up pretty well.

I might get your point better if you sent a patch.

What problems exacly are you referring to?

Besides the AMD Elan cpufreq driver I see nothing where CONFIG_MELAN gave you any real difference (except your highest goal is to avoid a recompilation when switching from the Pentium 4 to the AMD Elan - but I doubt the really "prevents development").

But I'm not religious about this issue. Let Robert decide, the Elan support is his child.

What's wrong wih the -march=i486 Robert suggested?

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Hi,

I've not followed the 2.6 development regarding the arch selection that closely; let's collect arguments:

- Is it still possible to run a -march=i486 built kernel on a pentium? IMHO It would be good to optimize the code for i486, but I'm not that familiar with how good gcc optimizes for 486 that I can comment this.

- I personally work with lots of cross architectures like ARM, so cross compiling for an embedded system is no problem for me. But if people want to test stuff on their pentiums I also have no problem with that.

Other arguments?

Robert

 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Hi Robert,

yes, since a Pentium supports a superset of the 486 gcc can't optimize for a 486 in a way that the code won't run on a Pentium.

The only reason why I sent the patch to make the AMD Elan a separate subarch was the CLOCK_TICK_RATE #ifdef in include/asm-i386/timex.h .

It should be possible to change it to a variable (as with CONFIG_X86_PC9800) if both the Elan and a different cpu are supported if this is really a required use.

If this is the solution you prefer, how would you do runtime detection for the AMD Elan?

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

I don't think you need a runtime detection. All that's needed is the ability to set the clock divisor to a slightly different value than the default. It doesn't need some special architecture because that will prevent setting other things like SMP. And yes, the embedded AMDs we use here have the SMP spin-locks because it is necessary to completely test the operating system independently of the target system. This is done by running my development workstation, a Pentium with two CPUs with the exact same OS. The modules are, of course, different, actually mostly missing on the target system because only Analogic-specific hardware interface modules are used plus the RAM disk.

I just set my workstation time when I log in in the morning. In a whole day it's only off by:

Script started on Tue Jan 20 17:25:37 2004

$ nettime time-a.timefreq.bldrdoc.gov
Reference time = Tue Jan 20 17:22:26 2004
       My time = Tue Jan 20 17:25:54 2004
    Difference = 208 seconds
   Time set by   time-a.timefreq.bldrdoc.gov (132.163.4.101)
$ exit
exit
Script done on Tue Jan 20 17:22:36 2004

208 seconds. As long as I don't change it during a compile, everything is fine.

So, again, please don't change anything that prevents me and others from using the AMD operating system on an ordinary workstation. Otherwise, I'll have to make some stupid embedded test software that exercises the OS on the AMD to get by the FDA requirements for independent testing of the OS. I would also have to re-certify our testing procedure.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

This is a VERY bad idea. If you would take a look at linux/time.h at the code to convert jiffies<->timeval/timespec you will see some very long expressions. This code is FAST but only because of constants which allow gcc to do most of the work at compile time. If you change CLOCK_TICK_RATE this will NOT be true and a lot of work will be done at run time. It might be instructive to compile one of these conversions and look at the cpp output. Last time I looked it was about 1/2 page of wall to wall expression which reduces to one MPY and shift (or there about).

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

I guess some code to dynamically check for AMD ELAN would make the time drift problem go away, right? I did notice a description of how to detect an elan in one of the elan manuals. That stuff does not seem to have made its way into the kernel, has it? Should it?

/A

- move "struct movsl_mask movsl_mask" to usercopy.c (CONFIG_X86_INTEL_USERCOPY is used on non-Intel CPUs)

diffstat output:

 arch/i386/kernel/cpu/intel.c |    7 -------
 arch/i386/lib/usercopy.c     |    7 +++++++
 2 files changed, 7 insertions(+), 7 deletions(-)

@@ -12,13 +12,6 @@
 
 #include "cpu.h"
 
-#ifdef CONFIG_X86_INTEL_USERCOPY
-/*
- * Alignment at which movsl is preferred for bulk memory copies.
- */
-struct movsl_mask movsl_mask;
-#endif
-
 /*
  *	Early probe support logic for ppro memory erratum #50
  *

@@ -12,6 +12,13 @@
 #include <asm/uaccess.h>
 #include <asm/mmx.h>
 
+#ifdef CONFIG_X86_INTEL_USERCOPY
+/*
+ * Alignment at which movsl is preferred for bulk memory copies.
+ */
+struct movsl_mask movsl_mask;
+#endif
+
 static inline int __movsl_is_ok(unsigned long a1, unsigned long a2, unsigned long n)
 {
 #ifdef CONFIG_X86_INTEL_USERCOPY

- make arch/i386/kernel/cpu/Makefile CPU specific

diffstat output:

 arch/i386/kernel/cpu/Makefile |   34 +++++++++++++++++++++++++---------
 arch/i386/kernel/cpu/common.c |   27 +++++++++++++++++++++++++++
 arch/i386/mm/init.c           |    6 +++++-
 3 files changed, 57 insertions(+), 10 deletions(-)

@@ -2,16 +2,32 @@
 # Makefile for x86-compatible CPU details and quirks
 #
 
-obj-y	:=	common.o proc.o
+obj-y			:=	common.o proc.o
+
+
+obj-$(CONFIG_CPU_486)		+=	amd.o
+obj-$(CONFIG_CPU_586)		+=	amd.o
+obj-$(CONFIG_CPU_K6)		+=	amd.o
+obj-$(CONFIG_CPU_K7)		+=	amd.o
+obj-$(CONFIG_CPU_K8)		+=	amd.o
+
+obj-$(CONFIG_CPU_WINCHIP)	+=	centaur.o
+obj-$(CONFIG_CPU_CYRIXIII)	+=	centaur.o
+obj-$(CONFIG_CPU_VIAC3_2)	+=	centaur.o
+
+obj-$(CONFIG_CPU_486)		+=	cyrix.o
+obj-$(CONFIG_CPU_586)		+=	cyrix.o
+
+obj-$(CONFIG_CPU_INTEL)		+=	intel.o
+
+obj-$(CONFIG_CPU_586)		+=	nexgen.o
+
+obj-$(CONFIG_CPU_586)		+=	rise.o
+
+obj-$(CONFIG_CPU_CRUSOE)	+=	transmeta.o
+
+obj-$(CONFIG_CPU_486)		+=	umc.o
 
-obj-y	+=	amd.o
-obj-y	+=	cyrix.o
-obj-y	+=	centaur.o
-obj-y	+=	transmeta.o
-obj-y	+=	intel.o
-obj-y	+=	rise.o
-obj-y	+=	nexgen.o
-obj-y	+=	umc.o
 
 obj-$(CONFIG_X86_MCE)	+=	mcheck/
 

@@ -434,15 +434,42 @@
 
 void __init early_cpu_init(void)
 {
+
+#if defined(CONFIG_CPU_INTEL)
 	intel_cpu_init();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586)
 	cyrix_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
 	nsc_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586) || defined(CONFIG_CPU_K6) || defined(CONFIG_CPU_K7) || defined(CONFIG_CPU_K8)
 	amd_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 	centaur_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_CRUSOE)
 	transmeta_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	rise_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	nexgen_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
 	umc_init_cpu();
+#endif
 
 #ifdef CONFIG_DEBUG_PAGEALLOC
 	/* pse is not compatible with on-the-fly unmapping,

@@ -423,8 +423,12 @@
 	if (!mem_map)
 		BUG();
 #endif
-	
+
+#ifdef CONFIG_CPU_686
 	bad_ppro = ppro_with_ram_bug();
+#else
+	bad_ppro = 0;
+#endif
 
 #ifdef CONFIG_HIGHMEM
 	/* check that fixmap and pkmap do not overlap */

- make arch/i386/kernel/cpu/mtrr/Makefile CPU specific

diffstat output:

 arch/i386/kernel/cpu/mtrr/Makefile |   14 ++++++++++----
 arch/i386/kernel/cpu/mtrr/main.c   |   14 ++++++++++++++
 2 files changed, 24 insertions(+), 4 deletions(-)

@@ -1,5 +1,11 @@
-obj-y		:= main.o if.o generic.o state.o
-obj-y		+= amd.o
-obj-y		+= cyrix.o
-obj-y		+= centaur.o
+obj-y				:= main.o if.o generic.o state.o
+
+obj-$(CONFIG_CPU_K6)		+= amd.o
+
+obj-$(CONFIG_CPU_586)		+= cyrix.o
+
+obj-$(CONFIG_CPU_WINCHIP)	+= centaur.o
+obj-$(CONFIG_CPU_CYRIXIII)	+= centaur.o
+obj-$(CONFIG_CPU_VIAC3_2)	+= centaur.o
+
 

@@ -475,12 +475,16 @@
 		printk(KERN_WARNING "mtrr: register: %d too big\n", reg);
 		goto out;
 	}
+
+#if defined(CONFIG_CPU_586)
 	if (is_cpu(CYRIX) && !use_intel()) {
 		if ((reg == 3) && arr3_protected) {
 			printk(KERN_WARNING "mtrr: ARR3 cannot be changed\n");
 			goto out;
 		}
 	}
+#endif
+
 	mtrr_if->get(reg, &lbase, &lsize, &ltype);
 	if (lsize < 1) {
 		printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);

@@ -536,9 +540,19 @@
 
 static void __init init_ifs(void)
 {
+
+#if defined(CONFIG_CPU_K6)
 	amd_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	cyrix_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 	centaur_init_mtrr();
+#endif
+
 }
 
 static void init_other_cpus(void)

I like this stuff, but I think the first two bits are probably better done in mainline proper, perhaps Andrew will consider them now that 2.6.0 is out. The -tiny approach is to make small tweaks on stuff without diverging far from the mainline infrastructure. I'm trying to keep most of the patches independent. I've basically already hacked my owned version of the third bit (cpu support code selection) in an earlier -tiny release, hadn't noticed the mtrr bits yet.

Matt Mackall : http://www.selenic.com : Linux development and consulting

The problem is, you aren't supposed to remove *any* cpu support code with the current scheme unless the kernel is definitely not supposed to run on that cpu. So a selection of 386 means you have to keep everything. This gets a bit hairy when you select eg. Pentium 4, and try to work out whether K7 should be supported or not...

Which is where Adrian's scheme comes in. I guess there are still probably a lot of other things with better complexity/size saving ratio though, but I would also like to see it in 2.6.

Your CONFIG_MEMPOOL is completely broken as you are no longer giving the same guarentees (you have no reserve at all). Might as well change it to CONFIG_DEADLOCK instead.

Jens Axboe

It's equivalent to a pool size of zero, yes, so deadlock odds are significantly higher with some usage scenarios. I'll add a big fat warning.

On the other hand, the existence of pre-allocated mempools can greatly increase the likelihood of starvation, oom, and deadlock on the rest of the system, especially as it becomes a greater percentage of the total free memory on a small system. In other words, I had to cut this corner to make running in 2M work with my config. When I merge CONFIG_BLOCK, it'll be more generally useful.

For the sake of our other readers, I'll point out that mempool doesn't intrinisically reduce deadlock odds to zero unless we have a hard limit on requests in flight that's strictly less than pool size.

Matt Mackall : http://www.selenic.com : Linux development and consulting

Maybe it would make more sense to have CONFIG_MEMPOOL=n just remove the mempool API entirely and have it imply CONFIG_BLOCK=n, CONFIG_NFS_FS=n, and CONFIG_NFSD=n? Just a thought.

It seems like a reasonalbe thing to omit for some tiny configs that don't need it, but if the API is provided it should probably work as expected.

-Mitch

NFS is a good example of why the guarantees of mempool are being overstated - it still needs to allocate SKBs to make progress and preallocating a pool for other data structures can make that fail where it otherwise might not. The pool size for NFS (32) is also completely arbitrary as far as I can tell.

The API _does_ work. It was a best effort with buffering before, it's a best effort without buffering now.

Matt Mackall : http://www.selenic.com : Linux development and consulting

På on , 07/01/2004 klokka 15:10, skreiv Matt Mackall:

If you are in a hardware situation where you actually care about the permanent size of that mempool, then you're barking up entirely the wrong tree: there is a hell of a lot more memory to reclaim from not having to build up all those nfs_page lists in the first place.

i.e. Rip out the entire asynchronous NFS read/write support, not just the mempools.

As for the usefulness of the mempools in the situation where you have asynchronous I/O: I agree that the socket layer screws any chance of a guarantee. So does the server if it goes down, the network itself can screw you,.... All in all, it is surprising how few guarantees NFS offers you.
I therefore see the mempools as more of an optimization that mainly avoid sleeping under a certain limited set of "reasonable" circumstances.

Cheers,
Trond

Precisely. In most scenarios it makes deadlocks possible, where it was safe before (more below).

It needs to be carefulled tuned, definitely.

That's not true, depends entirely on usage. It's not a magic wand. And you don't need a hard limit, you only need progress guarentee. Typically just a single pre-allocated object can make you 100% deadlock free, if stacking is not involved. So for most cases, I think it would be much better if you just hard wired min_nr to 1, that would move you from 90% to 99% safe :-)

Jens Axboe

Yes, definitely depends on usage.

Sure, I've considered that. I'll put an option for that on my todo list.

Matt Mackall : http://www.selenic.com : Linux development and consulting