* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-10 19:16 ` [PATCH ] VMSPLIT config options (with default config fixed) Mark Lord
@ 2006-01-10 17:37 ` Jeff V. Merkey
2006-01-10 19:27 ` Jens Axboe
` (3 subsequent siblings)
4 siblings, 0 replies; 28+ messages in thread
From: Jeff V. Merkey @ 2006-01-10 17:37 UTC (permalink / raw)
To: Mark Lord
Cc: Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
linux-kernel, Andrew Morton
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/
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-10 19:16 ` [PATCH ] VMSPLIT config options (with default config fixed) Mark Lord
2006-01-10 17:37 ` Jeff V. Merkey
@ 2006-01-10 19:27 ` Jens Axboe
2006-01-11 1:13 ` J.A. Magallon
` (2 subsequent siblings)
4 siblings, 0 replies; 28+ messages in thread
From: Jens Axboe @ 2006-01-10 19:27 UTC (permalink / raw)
To: Mark Lord
Cc: Linus Torvalds, Byron Stanoszek, Ingo Molnar, linux-kernel,
Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-10 19:16 ` [PATCH ] VMSPLIT config options (with default config fixed) Mark Lord
2006-01-10 17:37 ` Jeff V. Merkey
2006-01-10 19:27 ` Jens Axboe
@ 2006-01-11 1:13 ` J.A. Magallon
2006-01-11 10:15 ` Jens Axboe
2006-01-11 16:00 ` Greg Norris
2006-02-01 22:23 ` Herbert Poetzl
4 siblings, 1 reply; 28+ messages in thread
From: J.A. Magallon @ 2006-01-11 1:13 UTC (permalink / raw)
To: Mark Lord; +Cc: linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-11 1:13 ` J.A. Magallon
@ 2006-01-11 10:15 ` Jens Axboe
0 siblings, 0 replies; 28+ messages in thread
From: Jens Axboe @ 2006-01-11 10:15 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Mark Lord, linux-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-10 19:16 ` [PATCH ] VMSPLIT config options (with default config fixed) Mark Lord
` (2 preceding siblings ...)
2006-01-11 1:13 ` J.A. Magallon
@ 2006-01-11 16:00 ` Greg Norris
2006-01-11 17:13 ` Mark Lord
2006-02-01 22:23 ` Herbert Poetzl
4 siblings, 1 reply; 28+ messages in thread
From: Greg Norris @ 2006-01-11 16:00 UTC (permalink / raw)
To: linux-kernel
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!
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-11 16:00 ` Greg Norris
@ 2006-01-11 17:13 ` Mark Lord
2006-01-11 17:44 ` Greg Norris
2006-02-05 18:42 ` Barry K. Nathan
0 siblings, 2 replies; 28+ messages in thread
From: Mark Lord @ 2006-01-11 17:13 UTC (permalink / raw)
To: Greg Norris; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-11 17:13 ` Mark Lord
@ 2006-01-11 17:44 ` Greg Norris
2006-02-05 18:42 ` Barry K. Nathan
1 sibling, 0 replies; 28+ messages in thread
From: Greg Norris @ 2006-01-11 17:44 UTC (permalink / raw)
To: Mark Lord; +Cc: linux-kernel
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-11 17:13 ` Mark Lord
2006-01-11 17:44 ` Greg Norris
@ 2006-02-05 18:42 ` Barry K. Nathan
1 sibling, 0 replies; 28+ messages in thread
From: Barry K. Nathan @ 2006-02-05 18:42 UTC (permalink / raw)
To: Mark Lord; +Cc: Greg Norris, linux-kernel
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>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-01-10 19:16 ` [PATCH ] VMSPLIT config options (with default config fixed) Mark Lord
` (3 preceding siblings ...)
2006-01-11 16:00 ` Greg Norris
@ 2006-02-01 22:23 ` Herbert Poetzl
2006-02-02 11:04 ` Ulrich Mueller
4 siblings, 1 reply; 28+ messages in thread
From: Herbert Poetzl @ 2006-02-01 22:23 UTC (permalink / raw)
To: Mark Lord
Cc: Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
linux-kernel, Andrew Morton
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/
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-01 22:23 ` Herbert Poetzl
@ 2006-02-02 11:04 ` Ulrich Mueller
2006-02-02 20:55 ` Jan Engelhardt
0 siblings, 1 reply; 28+ messages in thread
From: Ulrich Mueller @ 2006-02-02 11:04 UTC (permalink / raw)
To: Herbert Poetzl
Cc: linux-kernel, Mark Lord, Jens Axboe, Linus Torvalds,
Byron Stanoszek, Ingo Molnar, Andrew Morton
>>>>> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-02 11:04 ` Ulrich Mueller
@ 2006-02-02 20:55 ` Jan Engelhardt
2006-02-03 22:39 ` Mark Lord
0 siblings, 1 reply; 28+ messages in thread
From: Jan Engelhardt @ 2006-02-02 20:55 UTC (permalink / raw)
To: Ulrich Mueller
Cc: Herbert Poetzl, linux-kernel, Mark Lord, Jens Axboe,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
>
>> 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
--
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-02 20:55 ` Jan Engelhardt
@ 2006-02-03 22:39 ` Mark Lord
2006-02-04 10:23 ` Ulrich Mueller
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Mark Lord @ 2006-02-03 22:39 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ulrich Mueller, Herbert Poetzl, linux-kernel, Jens Axboe,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-03 22:39 ` Mark Lord
@ 2006-02-04 10:23 ` Ulrich Mueller
2006-02-04 11:06 ` Jan Engelhardt
2006-02-04 10:36 ` Jens Axboe
2006-02-04 11:05 ` Jan Engelhardt
2 siblings, 1 reply; 28+ messages in thread
From: Ulrich Mueller @ 2006-02-04 10:23 UTC (permalink / raw)
To: Mark Lord
Cc: Jan Engelhardt, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
>>>>> 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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-04 10:23 ` Ulrich Mueller
@ 2006-02-04 11:06 ` Jan Engelhardt
0 siblings, 0 replies; 28+ messages in thread
From: Jan Engelhardt @ 2006-02-04 11:06 UTC (permalink / raw)
To: Ulrich Mueller
Cc: Mark Lord, Herbert Poetzl, linux-kernel, Jens Axboe,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
>
>> 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
--
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-03 22:39 ` Mark Lord
2006-02-04 10:23 ` Ulrich Mueller
@ 2006-02-04 10:36 ` Jens Axboe
2006-02-04 11:05 ` Jan Engelhardt
2 siblings, 0 replies; 28+ messages in thread
From: Jens Axboe @ 2006-02-04 10:36 UTC (permalink / raw)
To: Mark Lord
Cc: Jan Engelhardt, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-03 22:39 ` Mark Lord
2006-02-04 10:23 ` Ulrich Mueller
2006-02-04 10:36 ` Jens Axboe
@ 2006-02-04 11:05 ` Jan Engelhardt
2006-02-04 13:57 ` Mark Lord
2006-02-05 15:38 ` Arjan van de Ven
2 siblings, 2 replies; 28+ messages in thread
From: Jan Engelhardt @ 2006-02-04 11:05 UTC (permalink / raw)
To: Mark Lord
Cc: Ulrich Mueller, Herbert Poetzl, linux-kernel, Jens Axboe,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
>
> 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
--
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-04 11:05 ` Jan Engelhardt
@ 2006-02-04 13:57 ` Mark Lord
2006-02-05 15:32 ` J.A. Magallon
2006-02-05 15:38 ` Arjan van de Ven
1 sibling, 1 reply; 28+ messages in thread
From: Mark Lord @ 2006-02-04 13:57 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ulrich Mueller, Herbert Poetzl, linux-kernel, Jens Axboe,
Linus Torvalds, Byron Stanoszek, Ingo Molnar, Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-04 13:57 ` Mark Lord
@ 2006-02-05 15:32 ` J.A. Magallon
0 siblings, 0 replies; 28+ messages in thread
From: J.A. Magallon @ 2006-02-05 15:32 UTC (permalink / raw)
To: linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-04 11:05 ` Jan Engelhardt
2006-02-04 13:57 ` Mark Lord
@ 2006-02-05 15:38 ` Arjan van de Ven
2006-02-05 21:14 ` Jan Engelhardt
1 sibling, 1 reply; 28+ messages in thread
From: Arjan van de Ven @ 2006-02-05 15:38 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Mark Lord, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
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...
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-05 15:38 ` Arjan van de Ven
@ 2006-02-05 21:14 ` Jan Engelhardt
2006-02-05 21:19 ` Arjan van de Ven
0 siblings, 1 reply; 28+ messages in thread
From: Jan Engelhardt @ 2006-02-05 21:14 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Mark Lord, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
>> >
>> > 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
--
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-05 21:14 ` Jan Engelhardt
@ 2006-02-05 21:19 ` Arjan van de Ven
2006-02-06 14:56 ` Jan Engelhardt
0 siblings, 1 reply; 28+ messages in thread
From: Arjan van de Ven @ 2006-02-05 21:19 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Mark Lord, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
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)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-05 21:19 ` Arjan van de Ven
@ 2006-02-06 14:56 ` Jan Engelhardt
2006-02-07 0:41 ` Herbert Poetzl
0 siblings, 1 reply; 28+ messages in thread
From: Jan Engelhardt @ 2006-02-06 14:56 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Mark Lord, Ulrich Mueller, Herbert Poetzl, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
>> >> 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
--
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-06 14:56 ` Jan Engelhardt
@ 2006-02-07 0:41 ` Herbert Poetzl
2006-02-07 2:51 ` Mark Rustad
2006-02-07 9:38 ` Bernd Petrovitsch
0 siblings, 2 replies; 28+ messages in thread
From: Herbert Poetzl @ 2006-02-07 0:41 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Arjan van de Ven, Mark Lord, Ulrich Mueller, linux-kernel,
Jens Axboe, Linus Torvalds, Byron Stanoszek, Ingo Molnar,
Andrew Morton
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
> --
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-07 0:41 ` Herbert Poetzl
@ 2006-02-07 2:51 ` Mark Rustad
2006-02-07 9:38 ` Bernd Petrovitsch
1 sibling, 0 replies; 28+ messages in thread
From: Mark Rustad @ 2006-02-07 2:51 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Jan Engelhardt, Arjan van de Ven, Mark Lord, Ulrich Mueller,
linux-kernel, Jens Axboe, Linus Torvalds, Byron Stanoszek,
Ingo Molnar, Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH ] VMSPLIT config options (with default config fixed)
2006-02-07 0:41 ` Herbert Poetzl
2006-02-07 2:51 ` Mark Rustad
@ 2006-02-07 9:38 ` Bernd Petrovitsch
1 sibling, 0 replies; 28+ messages in thread
From: Bernd Petrovitsch @ 2006-02-07 9:38 UTC (permalink / raw)
To: Herbert Poetzl
Cc: Jan Engelhardt, Arjan van de Ven, Mark Lord, Ulrich Mueller,
linux-kernel, Jens Axboe, Linus Torvalds, Byron Stanoszek,
Ingo Molnar, Andrew Morton
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
^ permalink raw reply [flat|nested] 28+ messages in thread