Re: Why is "Memory split" Kconfig option only for EMBEDDED?

[linux@horizon.com]

> I have not had yet any problems with VMSPLIT_3G_OPT ever since I
> used it -- which dates back to when it was a feature of Con
> Kolivas's patchset (known as LOWMEM1G), [even] before it got
> merged in mainline.
>
> (Excluding the cases Adrian Bunk listed: WINE, which I don't use, and 
> also 'some Java programs' which I have not seen.)

Seconded.  I have several servers with 1G of memory, and appreciate the
option very much; I maintained it as a custom patch long before it
became a CONFIG option.

Turning on CONFIG_EMBEDDED makes it a bit annoying to be sure not to
play with any of the other far more dangerous options that enables.
(I suppose I could just maintain a local patch to remove that from Kconfig.)

The last I remember hearing, the vm system wasn't very happy with highem
much smaller than lowmem (128M/896M = 1/7) anyway.

There's nothing wrong with a stern warning, but I'd think that disabling
CONFIG_NET would break a lot more user-space programs, and that's not
protected.


How about the following (which also fixes a bug if you select VMSPLIT_2G
and HIGHEM; with 64-bit page tables, the split must be on a 1G boundary):

choice
	depends on EXPERIMENTAL
	prompt "Memory split"
	default VMSPLIT_3G
	help
	  Select the desired split between kernel and user memory.
	  If you are not absolutely sure what you are doing, leave this
	  option alone!

	  There are important efficiency reasons why the user address
	  space and the kernel address space must both fit into the 4G
	  linear virtual address space provided by the x86 architecture.

	  Normally, Linux divides this into 3G for user virtual memory
	  and 1G for kernel memory, which holds up to 896M of RAM plus all
	  memory-mapped peripheral (e.g. PCI) devices.	Excess RAM is ignored.

	  If the "High memory support" options are enabled, the excess memory
	  is available as "high memory", which can be used for user data,
	  including file system caches, but not kernel data structures.
	  However, accessing high memory from the kernel is slightly more
	  costly than low memory, as it has to be mapped into the kernel
	  address range first.

	  This option lets systems choose to have a larger "low memory" space,
	  either to avoid the need for high memory support entirely, or for
	  workloads which require particularly large kernel data structures.

	  The downside is that the available user address space is reduced.
	  While most programs do not care, this is an incompatible change
	  to the kernel binary interface, and must be made with caution.
	  Some programs that process a lot of data will work more slowly or
	  fail, and some programs that do clever things with virtual memory
	  will crash immediately.

	  In particular, changing this option from the default breaks valgrind
	  version 3.1.0, VMware, and some Java virtual machines.

	config VMSPLIT_3G
		bool "Default 896MB lowmem (3G/1G user/kernel split)"
	config VMSPLIT_3G_OPT
		depends on !HIGHMEM
		bool "1G lowmem (2.75G/1.25G user/kernel split)   CAUTION"
	config VMSPLIT_2G
		bool "1.875G lowmem (2G/2G user/kernel split)     CAUTION"
	config VMSPLIT_2G_OPT
		depends on !HIGHMEM
		bool "2G lowmem (1.875G/2.125G user/kernel split) CAUTION"
	config VMSPLIT_1G
		bool "2.875G lowmem (1G/3G user/kernel split)     CAUTION"
	config VMSPLIT_1G_OPT
		depends on !HIGHMEM
		bool "3G lowmem (896M/3.125G user/kernel split)   CAUTION"
endchoice

config PAGE_OFFSET
        hex
        default 0xB0000000 if VMSPLIT_3G_OPT
        default 0x80000000 if VMSPLIT_2G
        default 0x78000000 if VMSPLIT_2G_OPT
        default 0x40000000 if VMSPLIT_1G
        default 0x38000000 if VMSPLIT_1G_OPT
        default 0xC0000000

(Copyright on the above abandoned to the public domain.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/