[PATCH] VMSPLIT config options
authorMark Lord <lkml@rtr.ca>
Wed, 1 Feb 2006 11:06:11 +0000 (03:06 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Wed, 1 Feb 2006 16:53:21 +0000 (08:53 -0800)
Enable selection of different user/kernel VM splits for i386, including an
optimized mode for 1GB physical RAM, which gives the kernel a direct (non
HIGHMEM) mapping to the entire 1GB rather than just the first 896MB.

There is a similarly a similarly optimized mode for machines with exactly 2GB
of physical RAM.

This can speed up the kernel by avoiding having to create/destroy temporary
HIGHMEM mappings, and by not having to include HIGHMEM support at all on such
machines.  The flip side is that there's less virtual addressing left for
userspace in these alternatives, and some binary-only kernel modules may
misbehave unless rebuilt with the same VMSPLIT option as the main kernel
image.

Original idea/patch from Jens Axboe, modified based on suggestions from Linus
et al.

Signed-off-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
arch/i386/Kconfig
include/asm-i386/page.h

index 4e9e49a55ea8f1ec7708e92018f072213a68dcac..d86c865a7cd22b1d1892e03d3473b45767539677 100644 (file)
@@ -448,6 +448,43 @@ config HIGHMEM64G
 
 endchoice
 
+choice
+       depends on EXPERIMENTAL && !X86_PAE
+       prompt "Memory split"
+       default VMSPLIT_3G
+       help
+         Select the desired split between kernel and user memory.
+
+         If the address range available to the kernel is less than the
+         physical memory installed, the remaining memory will be available
+         as "high memory". Accessing high memory is a little more costly
+         than low memory, as it needs to be mapped into the kernel first.
+         Note that increasing the kernel address space limits the range
+         available to user programs, making the address space there
+         tighter.  Selecting anything other than the default 3G/1G split
+         will also likely make your kernel incompatible with binary-only
+         kernel modules.
+
+         If you are not absolutely sure what you are doing, leave this
+         option alone!
+
+       config VMSPLIT_3G
+               bool "3G/1G user/kernel split"
+       config VMSPLIT_3G_OPT
+               bool "3G/1G user/kernel split (for full 1G low memory)"
+       config VMSPLIT_2G
+               bool "2G/2G user/kernel split"
+       config VMSPLIT_1G
+               bool "1G/3G user/kernel split"
+endchoice
+
+config PAGE_OFFSET
+       hex
+       default 0xB0000000 if VMSPLIT_3G_OPT
+       default 0x78000000 if VMSPLIT_2G
+       default 0x40000000 if VMSPLIT_1G
+       default 0xC0000000
+
 config HIGHMEM
        bool
        depends on HIGHMEM64G || HIGHMEM4G
index 73296d9924fb36ac196937e2d9d63e32f978aa2c..997ca5d17876dc410c6007398d138ebe6ad54545 100644 (file)
@@ -110,10 +110,10 @@ extern int page_is_ram(unsigned long pagenr);
 #endif /* __ASSEMBLY__ */
 
 #ifdef __ASSEMBLY__
-#define __PAGE_OFFSET          (0xC0000000)
+#define __PAGE_OFFSET          CONFIG_PAGE_OFFSET
 #define __PHYSICAL_START       CONFIG_PHYSICAL_START
 #else
-#define __PAGE_OFFSET          (0xC0000000UL)
+#define __PAGE_OFFSET          ((unsigned long)CONFIG_PAGE_OFFSET)
 #define __PHYSICAL_START       ((unsigned long)CONFIG_PHYSICAL_START)
 #endif
 #define __KERNEL_START         (__PAGE_OFFSET + __PHYSICAL_START)