Support worst case cache line sizes as config option

This mirrors a change that has been in the SuSE/aa 2.4 kernel for a long time.

For a generic binary kernel you really want to assume the worst case cache line size. That's the P4's 128 byte currently.

The overhead of having the cache line size bigger on other CPUs is not that bad, but if it is too small it will cost you dearly on SMP and even a bit on UP in device drivers.

This patch adds a new CONFIG_X86_GENERIC option for this. It currently only forces 128byte cache lines, but could be used for more in the future.

diff -u linux-gencpu/arch/i386/Kconfig-o linux-gencpu/arch/i386/Kconfig
@@ -273,6 +273,13 @@
 
 endchoice
 
+config X86_GENERIC
+       bool "Generic x86 support" 
+       help
+       	  Include some tuning for non selected x86 CPUs too.
+	  when it has moderate overhead. This is intended for generic 
+	  distributions kernels.
+
 #
 # Define implied options from the CPU selection here
 #

@@ -288,10 +295,10 @@
 
 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 MPENTIUM4
 
 config RWSEM_GENERIC_SPINLOCK
 	bool

I don't know if it matters, probably not.

-Andi

M386 is tuning for the Intel 386

X86_GENERIC is "try to tune for all CPUs if possible"

Admittedly the other options could be changed to

default "4" if (MELAN || M486 || M386) && !X86_GENERIC

but that looked a bit too ugly and it seems to work even without.

-Andi

M386 says that the minimum CPU supported is the 386 - and all CPUs above are supported, too. E.g.:

config X86_PPRO_FENCE

        bool
        depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
        default y

config X86_F00F_BUG

        bool
        depends on M586MMX || M586TSC || M586 || M486 || M386
        default y

Your approach as well as the approach I'm currently working on breaks the current semantics that a plain M386 produces a kernel that runs on all CPUs.

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

Good, because I _have_ a 386 and want a kernel that is tuned for it, not a generic kernel.

cheers,
-- Jamie

You seem to be completely confused about what the patch is doing. CONFIG_X86_GENERIC does not break anything.

A kernel compiled with it will still run fine on the 386 (or whatever the main CPU selection was). All it does is to make the worst case of the kernel running on a CPU with larger cache sizes that your "main" CPU not as bad.

In fact if you read my patchkits in the last days they are all aimed at making kernels run on more CPUs, not less. The eventual
goal is to make Athlon kernels run on all 686+ class CPUs, and P4 kernels run on all 686+ CPUs, and 386 kernels run well on all CPUs without bad performance penalties.

M386 is a quite bad example here anyways. The standard situation
is that people compile an SMP kernel for the P2 (which seems to be "the generic cpu" these days[1]). That kernel is compiled with a cache size of 32bytes.

This 32byte cache size is used to avoid false sharing in a lot of data structures; e.g. arrays of per CPU data are usually padded to cache line size to make sure each CPU has its own cache line in the array. This unfortunately does not work when you run it on a CPU with a bigger cache line; like an Athlon with 64byte cache line or an P4 with 128 byte cache. In this case a lot of performance will be lost on SMP because multiple CPUs will fight for the data on a single cache line ("false sharing"). Always padding to the worst case cache line size avoids this problem.

The issue is not an SMP only problem. Some device drivers already use the cache line size to optimize PCI bus performance, and they have penalties when the data is incorrectly padded.

Increasing the cache line size costs a bit of memory for more padding, but overall the overhead is quite reasonable.

As far Jamies point: if you don't want your 386 kernel to be optimized for the worst case just don't enable the X86_GENERIC option.

-Andi

[1] ignoring K6 and C3, which are too poor to have CMOV.