This commit was manufactured by cvs2svn to create tag

[linux-2.6.git] / arch / i386 / Kconfig

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index af97501..d4c5d79 100644 (file)
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -424,6 +424,54 @@ config X86_OOSTORE
        depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR
        default y
 
+config X86_4G
+       bool "4 GB kernel-space and 4 GB user-space virtual memory support"
+       help
+          This option is only useful for systems that have more than 1 GB
+          of RAM.
+
+          The default kernel VM layout leaves 1 GB of virtual memory for
+          kernel-space mappings, and 3 GB of VM for user-space applications.
+          This option ups both the kernel-space VM and the user-space VM to
+          4 GB.
+
+          The cost of this option is additional TLB flushes done at
+          system-entry points that transition from user-mode into kernel-mode.
+          I.e. system calls and page faults, and IRQs that interrupt user-mode
+          code. There's also additional overhead to kernel operations that copy
+          memory to/from user-space. The overhead from this is hard to tell and
+          depends on the workload - it can be anything from no visible overhead
+          to 20-30% overhead. A good rule of thumb is to count with a runtime
+          overhead of 20%.
+
+          The upside is the much increased kernel-space VM, which more than
+          quadruples the maximum amount of RAM supported. Kernels compiled with
+          this option boot on 64GB of RAM and still have more than 3.1 GB of
+          'lowmem' left. Another bonus is that highmem IO bouncing decreases,
+          if used with drivers that still use bounce-buffers.
+
+          There's also a 33% increase in user-space VM size - database
+          applications might see a boost from this.
+
+          But the cost of the TLB flushes and the runtime overhead has to be
+          weighed against the bonuses offered by the larger VM spaces. The
+          dividing line depends on the actual workload - there might be 4 GB
+          systems that benefit from this option. Systems with less than 4 GB
+          of RAM will rarely see a benefit from this option - but it's not
+          out of question, the exact circumstances have to be considered.
+
+config X86_SWITCH_PAGETABLES
+       def_bool X86_4G
+
+config X86_4G_VM_LAYOUT
+       def_bool X86_4G
+
+config X86_UACCESS_INDIRECT
+       def_bool X86_4G
+
+config X86_HIGH_ENTRY
+       def_bool X86_4G
+
 config HPET_TIMER
        bool "HPET Timer Support"
        help
@@ -1289,15 +1337,6 @@ config FRAME_POINTER
          If you don't debug the kernel, you can say N, but we may not be able
          to solve problems without frame pointers.
 
-config 4KSTACKS
-       bool "Use 4Kb for kernel stacks instead of 8Kb"
-       help
-         If you say Y here the kernel will use a 4Kb stacksize for the
-         kernel stack attached to each process/thread. This facilitates
-         running more threads on a system and also reduces the pressure
-         on the VM subsystem for higher order allocations. This option
-         will also use IRQ stacks to compensate for the reduced stackspace.
-
 config X86_FIND_SMP_CONFIG
        bool
        depends on X86_LOCAL_APIC || X86_VOYAGER
@@ -1310,6 +1349,8 @@ config X86_MPPARSE
 
 endmenu
 
+source "kernel/vserver/Kconfig"
+
 source "security/Kconfig"
 
 source "crypto/Kconfig"