diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 53d6237..32356f2 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -578,7 +578,8 @@ endchoice
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
- default 0x78000000 if VMSPLIT_2G
+ default 0x78000000 if (VMSPLIT_2G && !X86_PAE)
+ default 0x80000000 if (VMSPLIT_2G && X86_PAE)
default 0x40000000 if VMSPLIT_1G
default 0xC0000000
On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
> Andi Kleen a ?crit :
> >From: [email protected]
> >
> >When in PAE mode we require that the user kernel divide to be
> >on a 1G boundary. The 2G/2G split does not have that property
> >so require !X86_PAE
> >
> >Signed-off-by: Eric W. Biederman <[email protected]>
> >---
> > arch/i386/Kconfig | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> >diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> >index 1a94a73..80003de 100644
> >--- a/arch/i386/Kconfig
> >+++ b/arch/i386/Kconfig
> >@@ -570,6 +570,7 @@ choice
> > depends on !HIGHMEM
> > bool "3G/1G user/kernel split (for full 1G low memory)"
> > config VMSPLIT_2G
> >+ depends on !X86_PAE
> > bool "2G/2G user/kernel split"
> > config VMSPLIT_1G
> > bool "1G/3G user/kernel split"
>
> Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change
> PAGE_OFFSET to 0x8000000 instead of 0x78000000 and keep 2G/2G split ?
I dropped the patch for now.
> [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE
>
> When in PAE mode we require that the user kernel divide to be
> on a 1G boundary. We must therefore make sure PAGE_OFFSET is correctlty
> defined in the 2G/2G split and PAE mode.
Looks reasonable. Did you test both cases? wli, ok for you too?
-Andi
On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>> Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change
>> PAGE_OFFSET to 0x8000000 instead of 0x78000000 and keep 2G/2G split ?
On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
> I dropped the patch for now.
I'm more miffed about what it's cleaning up after than the patch itself.
On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>> [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE
>> When in PAE mode we require that the user kernel divide to be
>> on a 1G boundary. We must therefore make sure PAGE_OFFSET is correctlty
>> defined in the 2G/2G split and PAE mode.
On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
> Looks reasonable. Did you test both cases? wli, ok for you too?
Sorry about the delay in replying.
I don't mind so long as we're not letting doorstop configs through. I'd
probably do something more like
Index: sched/arch/i386/Kconfig
===================================================================
--- sched.orig/arch/i386/Kconfig 2007-05-01 04:35:47.065162310 -0700
+++ sched/arch/i386/Kconfig 2007-05-01 04:36:50.100754504 -0700
@@ -571,6 +571,9 @@
bool "3G/1G user/kernel split (for full 1G low memory)"
config VMSPLIT_2G
bool "2G/2G user/kernel split"
+ config VMSPLIT_2G_OPT
+ depends on !HIGHMEM
+ bool "2G/2G user/kernel split (for full 2G low memory)"
config VMSPLIT_1G
bool "1G/3G user/kernel split"
endchoice
@@ -578,7 +581,8 @@
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
- default 0x78000000 if VMSPLIT_2G
+ default 0x80000000 if VMSPLIT_2G
+ default 0x78000000 if VMSPLIT_2G_OPT
default 0x40000000 if VMSPLIT_1G
default 0xC0000000
as a stopgap measure, but I'm not all that interested in grabbing patch
credits where others could do it easily enough. Either of the config
alterations is fine by me as they now stand; maybe Eric Dumazet might
care to do something like my suggestion at some point.
My interest here is in approaches that aren't really centered around
config options. Those are pmd handling for 1GB-unaligned PAGE_OFFSET
in PAE and dynamic vmallocspace reservation, the latter of which is
more complex than the first. I'd probably only do the pmd handling as
it's much easier than dynamic vmallocspace, which does substantial
violence to the core in order to reserve chunks of ZONE_NORMAL's
virtualspace so that no boot-time virtualspace reservations need to be
made for vmalloc(). Basically it would make vmalloc() proper use
physically contiguous memory and vmap() fiddle with ZONE_NORMAL
pagetables while reserving physical memory underlying the virtualspace
reserved for vmap() so that it's no longer necessary to carve
vmallocspace out of userspace to avoid highmem. That would occur at the
cost of runtime memory footprint of the rarely-called vmap() and
ZONE_NORMAL mapping updates. It would also alleviate pressure on
vmallocspace in configurations where it would be severely limited.
I'm doing a bit of thinking about this laptop-avoiding-highmem problem.
I've not come up with any better ideas than the dynamic vmallocspace
approach to avoid ABI damage while avoiding both highmem and sacrificing
memory for 1GB laptops, and slightly mitigating ABI damage for 2GB
laptops' highmem avoidance efforts. I'm thinking the applicability
isn't broad enough to merit the effort of dynamic vmallocspace. The pmd
fixup for 1GB-unaligned splits is not such a big deal in comparison.
-- wli
Bill Irwin wrote:
>
> I don't mind so long as we're not letting doorstop configs through. I'd
> probably do something more like
>
> Index: sched/arch/i386/Kconfig
> ===================================================================
> --- sched.orig/arch/i386/Kconfig 2007-05-01 04:35:47.065162310 -0700
> +++ sched/arch/i386/Kconfig 2007-05-01 04:36:50.100754504 -0700
> @@ -571,6 +571,9 @@
> bool "3G/1G user/kernel split (for full 1G low memory)"
> config VMSPLIT_2G
> bool "2G/2G user/kernel split"
> + config VMSPLIT_2G_OPT
> + depends on !HIGHMEM
> + bool "2G/2G user/kernel split (for full 2G low memory)"
> config VMSPLIT_1G
> bool "1G/3G user/kernel split"
> endchoice
> @@ -578,7 +581,8 @@
> config PAGE_OFFSET
> hex
> default 0xB0000000 if VMSPLIT_3G_OPT
> - default 0x78000000 if VMSPLIT_2G
> + default 0x80000000 if VMSPLIT_2G
> + default 0x78000000 if VMSPLIT_2G_OPT
> default 0x40000000 if VMSPLIT_1G
> default 0xC0000000
>
> as a stopgap measure, but I'm not all that interested in grabbing patch
..
Yup, I second that one. The idea of the original 2G split
was to avoid the need for HIGHMEM entirely, reducing overhead
on slower machines.
Having both kinds of splits is fine, but probably just the original one
with the !PAE is okay too.
-ml
Bill Irwin a ?crit :
> On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>>> Hum... We lose a usefull 2G/2G split. Should'nt we use a patch to change
>>> PAGE_OFFSET to 0x8000000 instead of 0x78000000 and keep 2G/2G split ?
>
> On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
>> I dropped the patch for now.
>
> I'm more miffed about what it's cleaning up after than the patch itself.
>
>
> On Tue, May 01, 2007 at 06:26:23AM +0200, Eric Dumazet wrote:
>>> [PATCH] i386 : Adjust CONFIG_PAGE_OFFSET in case of 2G/2G split and X86_PAE
>>> When in PAE mode we require that the user kernel divide to be
>>> on a 1G boundary. We must therefore make sure PAGE_OFFSET is correctlty
>>> defined in the 2G/2G split and PAE mode.
>
> On Tue, May 01, 2007 at 08:21:32AM +0200, Andi Kleen wrote:
>> Looks reasonable. Did you test both cases? wli, ok for you too?
>
> Sorry about the delay in replying.
>
> I don't mind so long as we're not letting doorstop configs through. I'd
> probably do something more like
>
> Index: sched/arch/i386/Kconfig
> ===================================================================
> --- sched.orig/arch/i386/Kconfig 2007-05-01 04:35:47.065162310 -0700
> +++ sched/arch/i386/Kconfig 2007-05-01 04:36:50.100754504 -0700
> @@ -571,6 +571,9 @@
> bool "3G/1G user/kernel split (for full 1G low memory)"
> config VMSPLIT_2G
> bool "2G/2G user/kernel split"
> + config VMSPLIT_2G_OPT
> + depends on !HIGHMEM
> + bool "2G/2G user/kernel split (for full 2G low memory)"
> config VMSPLIT_1G
> bool "1G/3G user/kernel split"
> endchoice
> @@ -578,7 +581,8 @@
> config PAGE_OFFSET
> hex
> default 0xB0000000 if VMSPLIT_3G_OPT
> - default 0x78000000 if VMSPLIT_2G
> + default 0x80000000 if VMSPLIT_2G
> + default 0x78000000 if VMSPLIT_2G_OPT
> default 0x40000000 if VMSPLIT_1G
> default 0xC0000000
>
> as a stopgap measure, but I'm not all that interested in grabbing patch
> credits where others could do it easily enough. Either of the config
> alterations is fine by me as they now stand; maybe Eric Dumazet might
> care to do something like my suggestion at some point.
Your patch is very fine Bill, please resubmit it with proper Signed-off-by
My first patch was a trivial reaction to try to keep alive 2G/2G split, yours
is better for fine tuning.
Thank you
Bill Irwin a ?crit :
>> as a stopgap measure, but I'm not all that interested in grabbing patch
>> credits where others could do it easily enough. Either of the config
>> alterations is fine by me as they now stand; maybe Eric Dumazet might
>> care to do something like my suggestion at some point.
On Tue, May 01, 2007 at 05:51:44PM +0200, Eric Dumazet wrote:
> Your patch is very fine Bill, please resubmit it with proper Signed-off-by
> My first patch was a trivial reaction to try to keep alive 2G/2G split,
> yours is better for fine tuning.
I was hoping you would submit it as an update, but maybe adding your
Signed-off-by: to my own will do.
-- wli
Only 1GB-aligned kernel/user splits are now handled for PAE. The
2GB/2GB split attempts to avoid aliasing vmallocspace with the 1:1
mapping for physical memory by using an actual split of 1.875/2.125
to accommodate 128MB of vmallocspace out of what would otherwise
be a full 2GB for userspace. That attempt disturbs the alignment
required by PAE for 2GB/2GB splits, and furthermore does not provide
a 2GB/2GB split as advertised.
This patch resolves the issues here in two manners. The first is
by providing a true 2GB/2GB split in addition to the 1.875/2.125
split. The second is by renaming the 1.875/2.125 split to
CONFIG_VMSPLIT_2G_OPT analogously to CONFIG_VMSPLIT_3G_OPT, which
performs a similar manuever to avoid aliasing vmallocspace with
the 1:1 mapping for physical memory around the 3GB boundary. With
the 1.875/2.125 split properly-named, its config option is then
tagged as depending on !HIGHMEM to express the PAE implementation's
current inability to deal with such unaligned splits.
This patch is essentially a combination of two patches, one written
by Eric Biederman and the other by Eric Dumazet. If they could add
their Signed-off-by: to this, I'd be much obliged.
Signed-off-by: William Irwin <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Mark Lord <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Andi Kleen <[email protected]>
Index: sched/arch/i386/Kconfig
===================================================================
--- sched.orig/arch/i386/Kconfig 2007-05-01 04:35:47.065162310 -0700
+++ sched/arch/i386/Kconfig 2007-05-01 04:36:50.100754504 -0700
@@ -571,6 +571,9 @@
bool "3G/1G user/kernel split (for full 1G low memory)"
config VMSPLIT_2G
bool "2G/2G user/kernel split"
+ config VMSPLIT_2G_OPT
+ depends on !HIGHMEM
+ bool "2G/2G user/kernel split (for full 2G low memory)"
config VMSPLIT_1G
bool "1G/3G user/kernel split"
endchoice
@@ -578,7 +581,8 @@
config PAGE_OFFSET
hex
default 0xB0000000 if VMSPLIT_3G_OPT
- default 0x78000000 if VMSPLIT_2G
+ default 0x80000000 if VMSPLIT_2G
+ default 0x78000000 if VMSPLIT_2G_OPT
default 0x40000000 if VMSPLIT_1G
default 0xC0000000
Bill Irwin <[email protected]> writes:
>
> Only 1GB-aligned kernel/user splits are now handled for PAE. The
> 2GB/2GB split attempts to avoid aliasing vmallocspace with the 1:1
> mapping for physical memory by using an actual split of 1.875/2.125
> to accommodate 128MB of vmallocspace out of what would otherwise
> be a full 2GB for userspace. That attempt disturbs the alignment
> required by PAE for 2GB/2GB splits, and furthermore does not provide
> a 2GB/2GB split as advertised.
>
> This patch resolves the issues here in two manners. The first is
> by providing a true 2GB/2GB split in addition to the 1.875/2.125
> split. The second is by renaming the 1.875/2.125 split to
> CONFIG_VMSPLIT_2G_OPT analogously to CONFIG_VMSPLIT_3G_OPT, which
> performs a similar manuever to avoid aliasing vmallocspace with
> the 1:1 mapping for physical memory around the 3GB boundary. With
> the 1.875/2.125 split properly-named, its config option is then
> tagged as depending on !HIGHMEM to express the PAE implementation's
> current inability to deal with such unaligned splits.
>
> This patch is essentially a combination of two patches, one written
> by Eric Biederman and the other by Eric Dumazet. If they could add
> their Signed-off-by: to this, I'd be much obliged.
>
> Signed-off-by: William Irwin <[email protected]>
> Cc: Eric Dumazet <[email protected]>
> Cc: Mark Lord <[email protected]>
> Cc: Eric W. Biederman <[email protected]>
> Cc: Andi Kleen <[email protected]>
Acked-by: "Eric W. Biederman" <[email protected]>
>
>
> Index: sched/arch/i386/Kconfig
> ===================================================================
> --- sched.orig/arch/i386/Kconfig 2007-05-01 04:35:47.065162310 -0700
> +++ sched/arch/i386/Kconfig 2007-05-01 04:36:50.100754504 -0700
> @@ -571,6 +571,9 @@
> bool "3G/1G user/kernel split (for full 1G low memory)"
> config VMSPLIT_2G
> bool "2G/2G user/kernel split"
> + config VMSPLIT_2G_OPT
> + depends on !HIGHMEM
> + bool "2G/2G user/kernel split (for full 2G low memory)"
> config VMSPLIT_1G
> bool "1G/3G user/kernel split"
> endchoice
> @@ -578,7 +581,8 @@
> config PAGE_OFFSET
> hex
> default 0xB0000000 if VMSPLIT_3G_OPT
> - default 0x78000000 if VMSPLIT_2G
> + default 0x80000000 if VMSPLIT_2G
> + default 0x78000000 if VMSPLIT_2G_OPT
> default 0x40000000 if VMSPLIT_1G
> default 0xC0000000
>
Eric W. Biederman a ?crit :
> Bill Irwin <[email protected]> writes:
>
>> Only 1GB-aligned kernel/user splits are now handled for PAE. The
>> 2GB/2GB split attempts to avoid aliasing vmallocspace with the 1:1
>> mapping for physical memory by using an actual split of 1.875/2.125
>> to accommodate 128MB of vmallocspace out of what would otherwise
>> be a full 2GB for userspace. That attempt disturbs the alignment
>> required by PAE for 2GB/2GB splits, and furthermore does not provide
>> a 2GB/2GB split as advertised.
>>
>> This patch resolves the issues here in two manners. The first is
>> by providing a true 2GB/2GB split in addition to the 1.875/2.125
>> split. The second is by renaming the 1.875/2.125 split to
>> CONFIG_VMSPLIT_2G_OPT analogously to CONFIG_VMSPLIT_3G_OPT, which
>> performs a similar manuever to avoid aliasing vmallocspace with
>> the 1:1 mapping for physical memory around the 3GB boundary. With
>> the 1.875/2.125 split properly-named, its config option is then
>> tagged as depending on !HIGHMEM to express the PAE implementation's
>> current inability to deal with such unaligned splits.
>>
>> This patch is essentially a combination of two patches, one written
>> by Eric Biederman and the other by Eric Dumazet. If they could add
>> their Signed-off-by: to this, I'd be much obliged.
>>
>> Signed-off-by: William Irwin <[email protected]>
>> Cc: Eric Dumazet <[email protected]>
>> Cc: Mark Lord <[email protected]>
>> Cc: Eric W. Biederman <[email protected]>
>> Cc: Andi Kleen <[email protected]>
>
> Acked-by: "Eric W. Biederman" <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
On Tuesday 01 May 2007 19:00:46 Bill Irwin wrote:
> Bill Irwin a ?crit :
> >> as a stopgap measure, but I'm not all that interested in grabbing patch
> >> credits where others could do it easily enough. Either of the config
> >> alterations is fine by me as they now stand; maybe Eric Dumazet might
> >> care to do something like my suggestion at some point.
>
> On Tue, May 01, 2007 at 05:51:44PM +0200, Eric Dumazet wrote:
> > Your patch is very fine Bill, please resubmit it with proper Signed-off-by
> > My first patch was a trivial reaction to try to keep alive 2G/2G split,
> > yours is better for fine tuning.
>
> I was hoping you would submit it as an update, but maybe adding your
> Signed-off-by: to my own will do.
Added thanks
-Andi