Re: [PATCH ] VMSPLIT config options (with default config fixed)

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Bodo Eggert]

Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>> Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
>> be a big impact to userspace, and there's no point in breaking everyone's
>> machines when advanced users can just reconfig/recompile to get what they
>> want.
>>
> What userspace programs do depend on it?

As far as I understand, user mode linux.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jeff Dike]

On Sun, Feb 05, 2006 at 09:20:55PM +0100, Bodo Eggert wrote:
> As far as I understand, user mode linux.

Nope, not any more.

UML used to load at the top of the user address space, hence a
dependency on a 3/1 split, but the default config now has UML loading
lower, where other processes load.

				Jeff

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Bernd Petrovitsch]

On Tue, 2006-02-07 at 01:41 +0100, Herbert Poetzl wrote:
> On Mon, Feb 06, 2006 at 03:56:34PM +0100, Jan Engelhardt wrote:
[...]
> > 
> > So, just as I did in the sample patch, the manual split shall depend on 
> > EMBEDDED. Those who run fat databases with big malloc/mmap assumptions 
> > don't probably belong to the group using CONFIG_EMBEDDED.
> 
> *sigh* well, the embeded folks are unlikely to have 1-3GB

ACK.
But don't be confused by the naming: CONFIG_EMBEDDED nowadays means
"options for people who know really what they do". It came originally
from the embedded world but applies now also to others. 
No one has come up with a better option name up to now ...

> why not use EXPERIMENTAL if you 'think' the option will
> hurt the database folks who do not know to configure their
> kernel ...

EXPERIMENTAL means (at least for me) "this may not really work" and is
IMHO orthogonal to CONFIG_EMBEDDED.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Mark Rustad]

On Feb 6, 2006, at 6:41 PM, Herbert Poetzl wrote:

> On Mon, Feb 06, 2006 at 03:56:34PM +0100, Jan Engelhardt wrote:
>>>>>> What userspace programs do depend on it?
>>>>>
>>>>> there is a lot of userspace that assumes they can do 2Gb or  
>>>>> even close
>>>>> to 3Gb of memory allocations. Databases, java, basically  
>>>>> anything with
>>>>> threads. Sure for most of these its a configuration option to  
>>>>> reduce
>>>>> this, but that still doesn't mean it's a good idea to change  
>>>>> from the
>>>>> existing behavior...
>>>>>
>>>> Not to mention that these (almost(*)) fail anyway when you have  
>>>> less than 2
>>>> GB of RAM.
>>>
>>> it's not really overcommit... it can also be file mmaps or shared  
>>> mmaps
>>> of say tmpfs files (the later is common with oracle actually)
>>
>> So, just as I did in the sample patch, the manual split shall  
>> depend on
>> EMBEDDED. Those who run fat databases with big malloc/mmap  
>> assumptions
>> don't probably belong to the group using CONFIG_EMBEDDED.
>
> *sigh* well, the embeded folks are unlikely to have 1-3GB
> why not use EXPERIMENTAL if you 'think' the option will
> hurt the database folks who do not know to configure their
> kernel ...

Embedded is not the same thing as small. 1GB is what the system I  
work on uses and it is "embedded". This new VMSPLIT is great, BTW.

-- 
Mark Rustad, MRustad@mac.com

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Herbert Poetzl]

On Mon, Feb 06, 2006 at 03:56:34PM +0100, Jan Engelhardt wrote:
> >> >> What userspace programs do depend on it?
> >> >
> >> >there is a lot of userspace that assumes they can do 2Gb or even close
> >> >to 3Gb of memory allocations. Databases, java, basically anything with
> >> >threads. Sure for most of these its a configuration option to reduce
> >> >this, but that still doesn't mean it's a good idea to change from the
> >> >existing behavior...
> >> > 
> >> Not to mention that these (almost(*)) fail anyway when you have less than 2 
> >> GB of RAM.
> >
> >it's not really overcommit... it can also be file mmaps or shared mmaps
> >of say tmpfs files (the later is common with oracle actually)
> 
> So, just as I did in the sample patch, the manual split shall depend on 
> EMBEDDED. Those who run fat databases with big malloc/mmap assumptions 
> don't probably belong to the group using CONFIG_EMBEDDED.

*sigh* well, the embeded folks are unlikely to have 1-3GB
why not use EXPERIMENTAL if you 'think' the option will
hurt the database folks who do not know to configure their
kernel ...

best,
Herbert

> Jan Engelhardt
> -- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jan Engelhardt]

>> >> What userspace programs do depend on it?
>> >
>> >there is a lot of userspace that assumes they can do 2Gb or even close
>> >to 3Gb of memory allocations. Databases, java, basically anything with
>> >threads. Sure for most of these its a configuration option to reduce
>> >this, but that still doesn't mean it's a good idea to change from the
>> >existing behavior...
>> > 
>> Not to mention that these (almost(*)) fail anyway when you have less than 2 
>> GB of RAM.
>
>it's not really overcommit... it can also be file mmaps or shared mmaps
>of say tmpfs files (the later is common with oracle actually)
>

So, just as I did in the sample patch, the manual split shall depend on 
EMBEDDED. Those who run fat databases with big malloc/mmap assumptions 
don't probably belong to the group using CONFIG_EMBEDDED.


Jan Engelhardt
-- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Arjan van de Ven]

On Sun, 2006-02-05 at 22:14 +0100, Jan Engelhardt wrote:
> >> >
> >> > Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
> >> > be a big impact to userspace, and there's no point in breaking everyone's
> >> > machines when advanced users can just reconfig/recompile to get what they want.
> >> >
> >> What userspace programs do depend on it?
> >
> >there is a lot of userspace that assumes they can do 2Gb or even close
> >to 3Gb of memory allocations. Databases, java, basically anything with
> >threads. Sure for most of these its a configuration option to reduce
> >this, but that still doesn't mean it's a good idea to change from the
> >existing behavior...
> > 
> Not to mention that these (almost(*)) fail anyway when you have less than 2 
> GB of RAM.

it's not really overcommit... it can also be file mmaps or shared mmaps
of say tmpfs files (the later is common with oracle actually)

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jan Engelhardt]

>> >
>> > Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
>> > be a big impact to userspace, and there's no point in breaking everyone's
>> > machines when advanced users can just reconfig/recompile to get what they want.
>> >
>> What userspace programs do depend on it?
>
>there is a lot of userspace that assumes they can do 2Gb or even close
>to 3Gb of memory allocations. Databases, java, basically anything with
>threads. Sure for most of these its a configuration option to reduce
>this, but that still doesn't mean it's a good idea to change from the
>existing behavior...
> 
Not to mention that these (almost(*)) fail anyway when you have less than 2 
GB of RAM.

(*) when finally writing to overcommitted memory

Yuck. That sounds like they depend on 64G/64bit allocations on 4G/32bit 
machines.


Jan Engelhardt
-- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Barry K. Nathan]

On 1/11/06, Mark Lord <lkml@rtr.ca> wrote:
> Greg Norris wrote:
> > Is there any benefit/point to enabling HIGHMEM when using this patch,
> > assuming that physical memory is smaller than the address space?  For
> > example, when using VMSPLIT_3G_OPT on a box with 1G of memory.
>
> No.  In fact, there should be a (very) tiny performance gain
> by NOT enabling HIGHMEM -- things like kmap() should get simpler.

Actually, IIRC if you have an x86 CPU (or x86-64 running a 32-bit
kernel) which has a no-execute bit, to support that (i.e. to have a
more secure system) you need to use HIGHMEM64G, no matter how much or
how little RAM you have.
--
-Barry K. Nathan <barryn@pobox.com>

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Arjan van de Ven]

On Sat, 2006-02-04 at 12:05 +0100, Jan Engelhardt wrote:
> >
> > Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
> > be a big impact to userspace, and there's no point in breaking everyone's
> > machines when advanced users can just reconfig/recompile to get what they want.
> >
> What userspace programs do depend on it?

there is a lot of userspace that assumes they can do 2Gb or even close
to 3Gb of memory allocations. Databases, java, basically anything with
threads. Sure for most of these its a configuration option to reduce
this, but that still doesn't mean it's a good idea to change from the
existing behavior...
 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

On Sat, 04 Feb 2006 08:57:23 -0500, Mark Lord <lkml@rtr.ca> wrote:

> Jan Engelhardt wrote:
> >
> > What userspace programs do depend on it?
> 
> That *is* the question, isn't it.
> We simply don't know, other than that this is
> a visible change to any program that cares.
> 
> Gratuitis breakage of userspace is pointless.
> 
> Empirically speaking, everything I use is working fine
> here with the 2G/2G split, but that's just not good enough
> reason to mindlessly break other people's userspace.
> 

The only thing I have seen that depends explicitely on this setting
is valgrind, but I think that CVS included some kind of runtime
configuration/selection.

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam8 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Mark Lord]

Jan Engelhardt wrote:
>
> What userspace programs do depend on it?

That *is* the question, isn't it.
We simply don't know, other than that this is
a visible change to any program that cares.

Gratuitis breakage of userspace is pointless.

Empirically speaking, everything I use is working fine
here with the 2G/2G split, but that's just not good enough
reason to mindlessly break other people's userspace.

Cheers

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jan Engelhardt]

>
>> Yes, that looks like a good idea.
>
>Couldn't this still be implemented entirely in Kconfig, without
>modifying page.h? Like in the following example:
>
>	[...]
>	config VMSPLIT_1G
>		bool "1G/3G user/kernel split"
>	config VMSPLIT_X
>		bool "Manual split"
>endchoice
>
>config PAGE_OFFSET
>	hex
>	range 0x40000000 0xC0000000    
>	prompt "Memory split address (must be aligned to 4096)" if VMSPLIT_X
>	[...]
>	default 0x40000000 if VMSPLIT_1G
>	default 0xC0000000
>

Well, if kconfig is able to do that, the better.



Jan Engelhardt
-- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jan Engelhardt]

>
> Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
> be a big impact to userspace, and there's no point in breaking everyone's
> machines when advanced users can just reconfig/recompile to get what they want.
>
What userspace programs do depend on it?


Jan Engelhardt
-- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jens Axboe]

On Fri, Feb 03 2006, Mark Lord wrote:
> >Maybe something like:
> >        config VMSPLIT_1G
> >                bool "1G/3G user/kernel split"
> >        config VMSPLIT_X
> >                bool "Manual split"
> >endchoice
> ...
> 
> Yes, that looks like a good idea.

Sounds like a huge mess to me. The manual kernel buffer size
configuration was bad enough, and this is much trickier. People have
enough problems even understanding what the option does, lets please
leave it as is with a few select options.

-- 
Jens Axboe

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Ulrich Mueller]

>>>>> On Fri, 03 Feb 2006, Mark Lord wrote:

>>> Hm, I wonder if we could have a more fine-grained choice of the
>>> boundary? There are also systems around with e.g. 1.25G or 1.5G of
>>> main memory.

>> Maybe something like:
>>	   config VMSPLIT_1G
>>		   bool "1G/3G user/kernel split"
>>	   config VMSPLIT_X
>>		   bool "Manual split"
>> endchoice
> ...

> Yes, that looks like a good idea.

Couldn't this still be implemented entirely in Kconfig, without
modifying page.h? Like in the following example:

	[...]
	config VMSPLIT_1G
		bool "1G/3G user/kernel split"
	config VMSPLIT_X
		bool "Manual split"
endchoice

config PAGE_OFFSET
	hex
	range 0x40000000 0xC0000000    
	prompt "Memory split address (must be aligned to 4096)" if VMSPLIT_X
	[...]
	default 0x40000000 if VMSPLIT_1G
	default 0xC0000000

Cheers
Uli

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Mark Lord]

Jan Engelhardt wrote:
>
> This sort of testing reminds me of Linus's 100->1000 Hz change
> ("I chose 1000 originally partly as a way to make sure that people that
>     assumed HZ was 100 would get a swift kick in the pants.")
> 
> Could we also do that with VMSPLIT?
> ("Let's choose VMSPLIT_2G to make sure that i386-people that assumed
> PAGE_OFFSET was 0xC0000000 would get...")

Mmm.. bad idea.  As much as I'd like the default to be 3GB_OPT, that would
be a big impact to userspace, and there's no point in breaking everyone's
machines when advanced users can just reconfig/recompile to get what they want.

>> Hm, I wonder if we could have a more fine-grained choice of the
>> boundary? There are also systems around with e.g. 1.25G or 1.5G of
>> main memory.
>>
> Maybe something like:
>         config VMSPLIT_1G
>                 bool "1G/3G user/kernel split"
>         config VMSPLIT_X
>                 bool "Manual split"
> endchoice
...

Yes, that looks like a good idea.

Cheers

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jan Engelhardt]

>
>> glad to see that the linux kernel is now ready for the 'idea'
>> I submitted a patch[1] for, more than a year ago -- which
>> unfortunately went unnoticed back then ...

BTW, I patched my local 2.6.16-rc1 with that patch and I run off 
VMSPLIT_3G_OPT quite well without problems. (Well, VMware gets it wrong, as 
usual, but nothing that I could not solved.) Even though I do not even have 
1 G but just 768 ;-)

This sort of testing reminds me of Linus's 100->1000 Hz change
("I chose 1000 originally partly as a way to make sure that people that
    assumed HZ was 100 would get a swift kick in the pants.")

Could we also do that with VMSPLIT?
("Let's choose VMSPLIT_2G to make sure that i386-people that assumed
PAGE_OFFSET was 0xC0000000 would get...")

>Hm, I wonder if we could have a more fine-grained choice of the
>boundary? There are also systems around with e.g. 1.25G or 1.5G of
>main memory.
>

Maybe something like:

        config VMSPLIT_1G
                bool "1G/3G user/kernel split"
        config VMSPLIT_X
                bool "Manual split"
endchoice

config VMSPLIT_MANUAL
    depends on VMSPLIT_X
    hex
    default 0xC0000000
    prompt "Memory split address (must be aligned to 4096)"


And in include/asm/page.h:

	#ifdef CONFIG_VMSPLIT_MANUAL
	#define __PAGE_OFFSET ((unsigned long)CONFIG_VMSPLIT_MANUAL)
	#else
	#define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)
	#endif

Not perfect, but a start.



Jan Engelhardt
-- 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Ulrich Mueller]

>>>>> On Wed, 01 Feb 2006, Herbert Poetzl wrote:

> glad to see that the linux kernel is now ready for the 'idea'
> I submitted a patch[1] for, more than a year ago -- which
> unfortunately went unnoticed back then ...

> [1] http://lkml.org/lkml/2004/10/9/126

Hm, I wonder if we could have a more fine-grained choice of the
boundary? There are also systems around with e.g. 1.25G or 1.5G of
main memory.

The following patch is against 2.6.16-rc1-mm4 and allows for steps of
256M between 1G and 3G.

Cheers
Uli


Signed-off-by: Ulrich Mueller <ulm@kph.uni-mainz.de>

diff -Nur linux-2.6.16-rc1-mm4.orig/arch/i386/Kconfig linux-2.6.16-rc1-mm4/arch/i386/Kconfig
--- linux-2.6.16-rc1-mm4.orig/arch/i386/Kconfig	2006-01-31 16:43:11.000000000 +0100
+++ linux-2.6.16-rc1-mm4/arch/i386/Kconfig	2006-01-31 17:16:44.000000000 +0100
@@ -470,18 +470,33 @@
 
 	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_2G75
+		bool "2.75G/1.25G user/kernel split (for full 1G low memory)"
+	config VMSPLIT_2G5
+		bool "2.5G/1.5G user/kernel split"
+	config VMSPLIT_2G25
+		bool "2.25G/1.75G user/kernel split"
 	config VMSPLIT_2G
 		bool "2G/2G user/kernel split"
+	config VMSPLIT_1G75
+		bool "1.75G/2.25G user/kernel split (for full 2G low memory)"
+	config VMSPLIT_1G5
+		bool "1.5G/2.5G user/kernel split"
+	config VMSPLIT_1G25
+		bool "1.25G/2/75G 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 0xB0000000 if VMSPLIT_2G75
+	default 0xA0000000 if VMSPLIT_2G5
+	default 0x90000000 if VMSPLIT_2G25
+	default 0x80000000 if VMSPLIT_2G
+	default 0x70000000 if VMSPLIT_1G75
+	default 0x60000000 if VMSPLIT_1G5
+	default 0x50000000 if VMSPLIT_1G25
 	default 0x40000000 if VMSPLIT_1G
 	default 0xC0000000
 

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Herbert Poetzl]

On Tue, Jan 10, 2006 at 02:16:19PM -0500, Mark Lord wrote:
> Okay, fixed the ordering of the "default" lines
> so that the Kconfig actually works correctly.
> 
> Best for Andrew to soak this one in -mm.

glad to see that the linux kernel is now ready for
the 'idea' I submitted a patch[1] for, more than a 
year ago -- which unfortunately went unnoticed back
then ...

cheers to Jens and Mark!

best,
Herbert

[1] http://lkml.org/lkml/2004/10/9/126

> Signed-off-by:  Mark Lord <mlord@pobox.com>
> 
> diff -u --recursive --new-file --exclude='.*' 
> linux-2.6.15/arch/i386/Kconfig linux/arch/i386/Kconfig
> --- linux-2.6.15/arch/i386/Kconfig	2006-01-02 22:21:10.000000000 -0500
> +++ linux/arch/i386/Kconfig	2006-01-10 12:02:40.000000000 -0500
> @@ -448,6 +448,43 @@
> 
>  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
> diff -u --recursive --new-file --exclude='.*' 
> linux-2.6.15/include/asm-i386/page.h linux/include/asm-i386/page.h
> --- linux-2.6.15/include/asm-i386/page.h	2006-01-02 
> 22:21:10.000000000 -0500
> +++ linux/include/asm-i386/page.h	2006-01-10 12:04:56.000000000 -0500
> @@ -110,10 +110,10 @@
>  #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)
> -
> 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/

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Greg Norris]

On Wed, Jan 11, 2006 at 12:13:06PM -0500, Mark Lord wrote:
> Greg Norris wrote:
> >Is there any benefit/point to enabling HIGHMEM when using this patch, 
> >assuming that physical memory is smaller than the address space?  For 
> >example, when using VMSPLIT_3G_OPT on a box with 1G of memory.
> 
> No.  In fact, there should be a (very) tiny performance gain
> by NOT enabling HIGHMEM -- things like kmap() should get simpler.

That's essentially what I thought, but it's nice to have some 
verification.  Thanx!

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Mark Lord]

Greg Norris wrote:
> Is there any benefit/point to enabling HIGHMEM when using this patch, 
> assuming that physical memory is smaller than the address space?  For 
> example, when using VMSPLIT_3G_OPT on a box with 1G of memory.

No.  In fact, there should be a (very) tiny performance gain
by NOT enabling HIGHMEM -- things like kmap() should get simpler.

Cheers

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Greg Norris]

Is there any benefit/point to enabling HIGHMEM when using this patch, 
assuming that physical memory is smaller than the address space?  For 
example, when using VMSPLIT_3G_OPT on a box with 1G of memory.

Thanx!

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jens Axboe]

On Wed, Jan 11 2006, J.A. Magallon wrote:
> I really like to see this in -mm, and finally in mainline.

It's in -mm now.

> My only objection is about the menu entry names and help. I think
> people building a kernel would not exactly understand what all this is
> about (even I think I don't have it realle clear).

If they don't, they should not touch the option...

> Is there any doc which states clearly somthing like:
> 
> - no highmem is the fastest
> - 4Gb introduces one indirection, so it is slower...(really ?)
> - 64Gb introduces two (PAE ?)
> 
> mixed with
> 
> - 3G/1G standard maping:
>    - nor user nor kernel can use any memory above 860 Mb
>    - user processes (my numbercruncher) can not allocate more than XGb
> - 2G/2G: idem:
>    - max memory seen by my linux system (not kernel, but kernel+userspace,
>    - how much can I allocate for a single process (how big my problem
>      can be ?)
> 
> If there is already a doc like that, it would be very interesting to
> have pointer/link to it in the help text.

I think the help text is good enough, but it would definitely be nice
with a fuller description of what exactly low and high memory is and the
implications of the various settings.

> For example, when I read this:
> 
> +	  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.
> 
> Does this mean that with 3/1 standard split, I still can use the lost
> 128 Mb for something ? I though I can't.

It tells you that the remaining memory is available as high memory, so
it's not lost of course. It also tells you that accessing this high
memory is indeed possible, but it's a little more costly since it needs
to be mapped temporarily into the kernel address space.

> Don't be too hard with me, just anxious to finally understand this...

No worries, perhaps you will be the one writing the Documentation/ bit
to accompany this then :-)

Basically the option boils down to how much virtual address space you
want to assign to the kernel and user space. The kernel can always
access all of memory, but in some cases part of that memory will be
available as high memory that needs to be mapped in first (see
references to kmap() and kmap_atomic() in the kernel). So whether
changing the mapping or using highmem is the best option for you,
depends entirely on what you run on that machine. If you require a huge
user address space, then you don't want to change away from the 3/1
user/kernel default setting. However, if you don't need the full 3G of
adress space to user apps, then you are better off increasing the kernel
address space range to get rid of the high memory mapping.

For the "typical" case of 1GB machine, using the _OPT setting to just
move the offset slightly is a really good choice as it only removes a
little bit of the user address range.

-- 
Jens Axboe

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

On Tue, 10 Jan 2006 14:16:19 -0500, Mark Lord <lkml@rtr.ca> wrote:

> Okay, fixed the ordering of the "default" lines
> so that the Kconfig actually works correctly.
> 
> Best for Andrew to soak this one in -mm.
> 
> Signed-off-by:  Mark Lord <mlord@pobox.com>
> 

Working nice on top of 2.6.15-mm2.
Even with the 'evil binary' nVidia driver 8178 ;).
In fact, I have been using the 1Gb-lowmem patch on -mm and the nVidia
driver since long ago, without problems.

I really like to see this in -mm, and finally in mainline.

My only objection is about the menu entry names and help. I think
people building a kernel would not exactly understand what all this is
about (even I think I don't have it realle clear).

Is there any doc which states clearly somthing like:

- no highmem is the fastest
- 4Gb introduces one indirection, so it is slower...(really ?)
- 64Gb introduces two (PAE ?)

mixed with

- 3G/1G standard maping:
   - nor user nor kernel can use any memory above 860 Mb
   - user processes (my numbercruncher) can not allocate more than XGb
- 2G/2G: idem:
   - max memory seen by my linux system (not kernel, but kernel+userspace,
   - how much can I allocate for a single process (how big my problem
     can be ?)

If there is already a doc like that, it would be very interesting to
have pointer/link to it in the help text.

For example, when I read this:

+	  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.

Does this mean that with 3/1 standard split, I still can use the lost
128 Mb for something ? I though I can't.

Don't be too hard with me, just anxious to finally understand this...

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jens Axboe]

On Tue, Jan 10 2006, Mark Lord wrote:
> Okay, fixed the ordering of the "default" lines
> so that the Kconfig actually works correctly.
> 
> Best for Andrew to soak this one in -mm.
> 
> Signed-off-by:  Mark Lord <mlord@pobox.com>

Signed-off-by: Jens Axboe <axboe@suse.de>

-- 
Jens Axboe

[PATCH ] VMSPLIT config options (with default config fixed)

[Mark Lord]

Okay, fixed the ordering of the "default" lines
so that the Kconfig actually works correctly.

Best for Andrew to soak this one in -mm.

Signed-off-by:  Mark Lord <mlord@pobox.com>

diff -u --recursive --new-file --exclude='.*' linux-2.6.15/arch/i386/Kconfig linux/arch/i386/Kconfig
--- linux-2.6.15/arch/i386/Kconfig	2006-01-02 22:21:10.000000000 -0500
+++ linux/arch/i386/Kconfig	2006-01-10 12:02:40.000000000 -0500
@@ -448,6 +448,43 @@

  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
diff -u --recursive --new-file --exclude='.*' linux-2.6.15/include/asm-i386/page.h linux/include/asm-i386/page.h
--- linux-2.6.15/include/asm-i386/page.h	2006-01-02 22:21:10.000000000 -0500
+++ linux/include/asm-i386/page.h	2006-01-10 12:04:56.000000000 -0500
@@ -110,10 +110,10 @@
  #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)

Re: [PATCH ] VMSPLIT config options (with default config fixed)

[Jeff V. Merkey]

Mark Lord wrote:

Looks good. I'll try this one.

Jeff

> Okay, fixed the ordering of the "default" lines
> so that the Kconfig actually works correctly.
>
> Best for Andrew to soak this one in -mm.
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> diff -u --recursive --new-file --exclude='.*' 
> linux-2.6.15/arch/i386/Kconfig linux/arch/i386/Kconfig
> --- linux-2.6.15/arch/i386/Kconfig 2006-01-02 22:21:10.000000000 -0500
> +++ linux/arch/i386/Kconfig 2006-01-10 12:02:40.000000000 -0500
> @@ -448,6 +448,43 @@
>
> 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
> diff -u --recursive --new-file --exclude='.*' 
> linux-2.6.15/include/asm-i386/page.h linux/include/asm-i386/page.h
> --- linux-2.6.15/include/asm-i386/page.h 2006-01-02 22:21:10.000000000 
> -0500
> +++ linux/include/asm-i386/page.h 2006-01-10 12:04:56.000000000 -0500
> @@ -110,10 +110,10 @@
> #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)
> -
> 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/
>