Mailing List Archive

* Jens Axboe <axboe@suse.de> wrote:

> Hi,
>
> It does annoy me that any 1G i386 machine will end up with 1/8th of
> the memory as highmem. A patch like this one has been used in various
> places since the early 2.4 days at least, is there a reason why it
> isn't merged yet? Note I just hacked this one up, but similar patches
> abound I'm sure. Bugs are mine.

yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
were possible. It was a larger patch to enable all this across x86, but
the Kconfig portion was removed a bit later because people _frequently_
misconfigured their kernels and then complained about the results.

so for now the trivial solution is to change the "C" to "8" in the
following line in include/asm-i386/page.h:

> #define __PAGE_OFFSET (0xC0000000)

instead of editing your .config :-)

Maybe we could try the Kconfig solution again, but it'll need alot
better documentation, dependency on KERNEL_DEBUG and some heavy warnings
all around.

Ingo
-
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/

On Tue, Jan 10 2006, Ingo Molnar wrote:
>
> * Jens Axboe <axboe@suse.de> wrote:
>
> > Hi,
> >
> > It does annoy me that any 1G i386 machine will end up with 1/8th of
> > the memory as highmem. A patch like this one has been used in various
> > places since the early 2.4 days at least, is there a reason why it
> > isn't merged yet? Note I just hacked this one up, but similar patches
> > abound I'm sure. Bugs are mine.
>
> yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
> were possible. It was a larger patch to enable all this across x86, but
> the Kconfig portion was removed a bit later because people _frequently_
> misconfigured their kernels and then complained about the results.

How is this different than all other sorts of misconfigurations? As far
as I can tell, the biggest "problem" for some is if they depend on some
binary module that will of course break with a different page offset.

For simplicity, I didn't add more than the 2/2 split, where we could add
even a 3/1 kernel/user or a 0.5/3.5 (I think sles8 had this).

> so for now the trivial solution is to change the "C" to "8" in the
> following line in include/asm-i386/page.h:
>
> > #define __PAGE_OFFSET (0xC0000000)
>
> instead of editing your .config :-)

:-)

That is what I have been doing, but that requires me to carry this patch
along with me all the time. So it annoys me!

I would have posted a simple patch moving it to 0xB0000000 which would
solve the problem for me as well, but I didn't because I'm sure people
would be screaming at me...

> Maybe we could try the Kconfig solution again, but it'll need alot
> better documentation, dependency on KERNEL_DEBUG and some heavy warnings
> all around.

The help text could definitely be improved, it was a 30 second hackup.
Why would you want to make it depend on DEBUG?

--
Jens Axboe

-
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/

On Tue, 10 Jan 2006, Jens Axboe wrote:

>> yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
>> were possible. It was a larger patch to enable all this across x86, but
>> the Kconfig portion was removed a bit later because people _frequently_
>> misconfigured their kernels and then complained about the results.
>
> How is this different than all other sorts of misconfigurations? As far
> as I can tell, the biggest "problem" for some is if they depend on some
> binary module that will of course break with a different page offset.
>
> For simplicity, I didn't add more than the 2/2 split, where we could add
> even a 3/1 kernel/user or a 0.5/3.5 (I think sles8 had this).

I prefer setting __PAGE_OFFSET to (0x78000000) on machines with 2GB of RAM.
This seems to let the kernel use the full 2GB of memory, rather than just
1920-1984 MB (at least back in 2.4 days).

-Byron

--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: byron@comtime.com
-
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/

On Tue, Jan 10 2006, Byron Stanoszek wrote:
> On Tue, 10 Jan 2006, Jens Axboe wrote:
>
> >>yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
> >>were possible. It was a larger patch to enable all this across x86, but
> >>the Kconfig portion was removed a bit later because people _frequently_
> >>misconfigured their kernels and then complained about the results.
> >
> >How is this different than all other sorts of misconfigurations? As far
> >as I can tell, the biggest "problem" for some is if they depend on some
> >binary module that will of course break with a different page offset.
> >
> >For simplicity, I didn't add more than the 2/2 split, where we could add
> >even a 3/1 kernel/user or a 0.5/3.5 (I think sles8 had this).
>
> I prefer setting __PAGE_OFFSET to (0x78000000) on machines with 2GB of RAM.
> This seems to let the kernel use the full 2GB of memory, rather than just
> 1920-1984 MB (at least back in 2.4 days).

That might indeed be a good idea for 2G/2G, in the same sense that
0xC0000000 is a silly default because of the many 1G machines out there.

--
Jens Axboe

-
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/

Jens Axboe writes:
> Hi,
>
> It does annoy me that any 1G i386 machine will end up with 1/8th of the
> memory as highmem. A patch like this one has been used in various places
> since the early 2.4 days at least, is there a reason why it isn't merged
> yet? Note I just hacked this one up, but similar patches abound I'm
> sure. Bugs are mine.
>
> Signed-off-by: Jens Axboe <axboe@suse.de>
>
> diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> index d849c68..0b2457b 100644
> --- a/arch/i386/Kconfig
> +++ b/arch/i386/Kconfig
> @@ -444,6 +464,24 @@ config HIGHMEM64G
>
> endchoice
>
> +choice
> + depends on NOHIGHMEM
> + prompt "Memory split"
> + default DEFAULT_3G
> + help
> + Select the wanted split between kernel and user memory. On a 1G
> + machine, the 3G/1G default split will result in 128MiB of high
> + memory. Selecting a 2G/2G split will make all of memory available
> + as low memory. Note that this will make your kernel incompatible
> + with binary only kernel modules.

2G/2G is not the only viable alternative. On my 1GB x86 box I'm
using "lowmem1g" patches for both 2.4 and 2.6, which results in
2.75G for user-space. I'm sure others have other preferences.
Any standard option for this should either have several hard-coded
alternatives, or should support arbitrary values (within reason).

(See http://www.csd.uu.se/~mikpe/linux/patches/*/patch-i386-lowmem1g-*
if you're interested.)

/Mikael
-
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/

On Tue, Jan 10 2006, Mikael Pettersson wrote:
> Jens Axboe writes:
> > Hi,
> >
> > It does annoy me that any 1G i386 machine will end up with 1/8th of the
> > memory as highmem. A patch like this one has been used in various places
> > since the early 2.4 days at least, is there a reason why it isn't merged
> > yet? Note I just hacked this one up, but similar patches abound I'm
> > sure. Bugs are mine.
> >
> > Signed-off-by: Jens Axboe <axboe@suse.de>
> >
> > diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
> > index d849c68..0b2457b 100644
> > --- a/arch/i386/Kconfig
> > +++ b/arch/i386/Kconfig
> > @@ -444,6 +464,24 @@ config HIGHMEM64G
> >
> > endchoice
> >
> > +choice
> > + depends on NOHIGHMEM
> > + prompt "Memory split"
> > + default DEFAULT_3G
> > + help
> > + Select the wanted split between kernel and user memory. On a 1G
> > + machine, the 3G/1G default split will result in 128MiB of high
> > + memory. Selecting a 2G/2G split will make all of memory available
> > + as low memory. Note that this will make your kernel incompatible
> > + with binary only kernel modules.
>
> 2G/2G is not the only viable alternative. On my 1GB x86 box I'm

Yes I know, as I wrote to Ingo I wanted to keep it really simple. It can
easily be extended, of course.

> using "lowmem1g" patches for both 2.4 and 2.6, which results in
> 2.75G for user-space. I'm sure others have other preferences.
> Any standard option for this should either have several hard-coded
> alternatives, or should support arbitrary values (within reason).

That's just asking for trouble, imho. We should provide some defaults
(that work well on 1G and 2G machines, for instance) and stick to that.

> (See http://www.csd.uu.se/~mikpe/linux/patches/*/patch-i386-lowmem1g-*
> if you're interested.)

It's similar to what I've been doing so far (just changing page.h to
0xb0000000). 0x80000000 might be a bad default as suggested by Byron, as
it just misses the full 2G.

0xb0000000 is a much better default, but I didn't think that would fly
as a patch.

--
Jens Axboe

-
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/

Hi,

> 0xb0000000 is a much better default, but I didn't think that would fly
> as a patch.

I think that will not fly with CONFIG_X86_PAE. In PAE mode the 3rd pmd
(for the 0xc0000000 => 0xffffffff kernel address range) is shared,
anything but 0xc000000 most likely needs some more hackery than just
changing PAGE_OFFSET. As the whole point of this split patchery is to
avoid highmem in the first place it maybe makes sense to have some
"optimize for 1/2/4/more GB main memory" config option which in turn
picks sane PAGE_OFFSET+HIGHMEM+PAE settings?

cheers,

Gerd

--
Gerd 'just married' Hoffmann <kraxel@suse.de>
I'm the hacker formerly known as Gerd Knorr.
-
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/

Jens Axboe wrote:
..
> +choice
> + depends on NOHIGHMEM

Is that dependency strictly needed here?

(Mark hurriedly applies patch and rebuilds kernel on 2G notebook..)

Cheers!
-
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/

On Tue, Jan 10 2006, Gerd Hoffmann wrote:
> Hi,
>
> >0xb0000000 is a much better default, but I didn't think that would fly
> >as a patch.
>
> I think that will not fly with CONFIG_X86_PAE. In PAE mode the 3rd pmd
> (for the 0xc0000000 => 0xffffffff kernel address range) is shared,
> anything but 0xc000000 most likely needs some more hackery than just
> changing PAGE_OFFSET. As the whole point of this split patchery is to
> avoid highmem in the first place it maybe makes sense to have some
> "optimize for 1/2/4/more GB main memory" config option which in turn
> picks sane PAGE_OFFSET+HIGHMEM+PAE settings?

The patch depends on NOHIGHMEM atm, so you can't select PAE and move the
page offset anyways.

--
Jens Axboe

-
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/

On Tue, Jan 10 2006, Mark Lord wrote:
> Jens Axboe wrote:
> ..
> >+choice
> >+ depends on NOHIGHMEM
>
> Is that dependency strictly needed here?

Probably not. Well at least it could be relaxed, I just wanted to be
safe and avoid any extra complications due to this.

> (Mark hurriedly applies patch and rebuilds kernel on 2G notebook..)

You may want to change the 2G split to 0x78000000 as noted by Byron,
then you can skip highmem completely if you so wanted.

--
Jens Axboe

-
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/

On Tue, Jan 10 2006, Gerd Hoffmann wrote:
> changing PAGE_OFFSET. As the whole point of this split patchery is to
> avoid highmem in the first place it maybe makes sense to have some
> "optimize for 1/2/4/more GB main memory" config option which in turn
> picks sane PAGE_OFFSET+HIGHMEM+PAE settings?

Forgot to comment on that... Yes that is indeed an option, but it's a
little complicated since it depends on the role of the machine. A file
server may want a very small user land virtual memory size, whereas a
database server may want the opposite. So I think it's still saner to
expose a select range of settings.

--
Jens Axboe

-
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/

On Tue, Jan 10 2006, Byron Stanoszek wrote:
> On Tue, 10 Jan 2006, Jens Axboe wrote:
>
> >>yes, i made it totally configurable in 2.4 days: 1:3, 2/2 and 3:1 splits
> >>were possible. It was a larger patch to enable all this across x86, but
> >>the Kconfig portion was removed a bit later because people _frequently_
> >>misconfigured their kernels and then complained about the results.
> >
> >How is this different than all other sorts of misconfigurations? As far
> >as I can tell, the biggest "problem" for some is if they depend on some
> >binary module that will of course break with a different page offset.
> >
> >For simplicity, I didn't add more than the 2/2 split, where we could add
> >even a 3/1 kernel/user or a 0.5/3.5 (I think sles8 had this).
>
> I prefer setting __PAGE_OFFSET to (0x78000000) on machines with 2GB of RAM.
> This seems to let the kernel use the full 2GB of memory, rather than just
> 1920-1984 MB (at least back in 2.4 days).

A newer version, trying to cater to the various comments in here.
Changes:

- Add 1G_OPT split, meant for 1GiB machines. Uses 0xB0000000
- Add 1G/3G split
- Move the 2G/2G a little, so the full 2GiB of ram can be mapped.
- Improve help text (I hope :)
- Make option depend on EXPERIMENTAL.
- Make the page.h a lot more readable.

---

Add option for configuring the page offset, to better optimize the
kernel for higher memory machines. Enables users to get rid of high
memory for eg a 1GiB machine.

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

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index d849c68..fcad8f7 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -444,6 +464,32 @@ config HIGHMEM64G

endchoice

+choice
+ depends on NOHIGHMEM && EXPERIMENTAL
+ prompt "Memory split"
+ default DEFAULT_3G
+ help
+ Select the wanted 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 selecting anything but the default 3G/1G split will make
+ your kernel incompatible with binary only modules.
+
+ config DEFAULT_3G
+ bool "3G/1G user/kernel split"
+ config DEFAULT_3G_OPT
+ bool "3G/1G user/kernel split (for full 1G low memory)"
+ config DEFAULT_2G
+ bool "2G/2G user/kernel split"
+ config DEFAULT_1G
+ bool "1G/3G user/kernel split"
+
+endchoice
+
config HIGHMEM
bool
depends on HIGHMEM64G || HIGHMEM4G
diff --git a/include/asm-i386/page.h b/include/asm-i386/page.h
index 73296d9..7da50a1 100644
--- a/include/asm-i386/page.h
+++ b/include/asm-i386/page.h
@@ -109,11 +109,23 @@ extern int page_is_ram(unsigned long pag

#endif /* __ASSEMBLY__ */

+#if defined(CONFIG_DEFAULT_3G)
+#define __PAGE_OFFSET_RAW (0xC0000000)
+#elif defined(CONFIG_DEFAULT_3G_OPT)
+#define __PAGE_OFFSET_RAW (0xB0000000)
+#elif defined(CONFIG_DEFAULT_2G)
+#define __PAGE_OFFSET_RAW (0x78000000)
+#elif defined(CONFIG_DEFAULT_1G)
+#define __PAGE_OFFSET_RAW (0x40000000)
+#else
+#error "Bad user/kernel offset"
+#endif
+
#ifdef __ASSEMBLY__
-#define __PAGE_OFFSET (0xC0000000)
+#define __PAGE_OFFSET __PAGE_OFFSET_RAW
#define __PHYSICAL_START CONFIG_PHYSICAL_START
#else
-#define __PAGE_OFFSET (0xC0000000UL)
+#define __PAGE_OFFSET ((unsigned long)__PAGE_OFFSET_RAW)
#define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
#endif
#define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)

--
Jens Axboe

-
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/

* Jens Axboe <axboe@suse.de> wrote:

> + Select the wanted 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.

make it _ALOT_ more clear that mere mortals should not touch this
option! Also, you do not mention the userspace-VM fragmentation issues.
Plus, if a user uses a 2G/2G split with more than 2G of RAM, the kernel
should print a warning that it's running with a non-default split. Do
the same if the user uses a non-default split with less than 960MB of
RAM.

> +
> + Note that selecting anything but the default 3G/1G split will make
> + your kernel incompatible with binary only modules.

it's not 'will' but 'may', and even then, tons of .config things can
break bin-only modules, so just skip this paragraph.

looks good to me otherwise, with the text fixes it's:

Acked-by: Ingo Molnar <mingo@elte.hu>

Ingo
-
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/

On Tue, 10 Jan 2006, Jens Axboe wrote:
>
> A newer version, trying to cater to the various comments in here.
> Changes:

Can we do one final cleanup? Do all the magic in _one_ place, namely the
x86 Kconfig file.

Also, I don't think the NOHIGHMEM dependency is necessarily correct. A
2G/2G split can be advantageous with a 16GB setup (you'll have more room
for dentries etc), but you obviously want to have HIGHMEM for that..

Do it something like this:

choice
depends on EXPERIMENTAL
prompt "Memory split"
default DEFAULT_3G
help
Select the wanted 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 selecting anything but the default 3G/1G split will make
your kernel incompatible with binary only modules.

config DEFAULT_3G
bool "3G/1G user/kernel split"
config DEFAULT_3G_OPT
bool "3G/1G user/kernel split (for full 1G low memory)"
config DEFAULT_2G
bool "2G/2G user/kernel split"
config DEFAULT_1G
bool "1G/3G user/kernel split"
endchoice

config PAGE_OFFSET
hex
default 0xC0000000
default 0xB0000000 if DEFAULT_3G_OPT
default 0x78000000 if DEFAULT_2G
default 0x40000000 if DEFAULT_1G

and then asm-i386/page.h can just do

#define __PAGE_OFFSET ((unsigned long)CONFIG_PAGE_OFFSET)

and you're done.

If you ever want to change the offsets, you're only changing the Kconfig
file, and as you can tell, the syntax is actually much _nicer_ that using
the C preprocessor, since these kinds of choices is exactly what the
Kconfig language is all about.

Please?

Linus
-
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/

Linus Torvalds wrote:
...
> Can we do one final cleanup? Do all the magic in _one_ place, namely the
> x86 Kconfig file.
...
> config DEFAULT_3G
> bool "3G/1G user/kernel split"
> config DEFAULT_3G_OPT
> bool "3G/1G user/kernel split (for full 1G low memory)"
> config DEFAULT_2G
> bool "2G/2G user/kernel split"
> config DEFAULT_1G
> bool "1G/3G user/kernel split"
...

Are "DEFAULT_*" really the best names to assign to these options?
For these options, I'd expect something like "VMUSER_*" or "USERMEM_*".

Cheers
-
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/

On Tue, 10 Jan 2006, Mark Lord wrote:
>
> Are "DEFAULT_*" really the best names to assign to these options?
> For these options, I'd expect something like "VMUSER_*" or "USERMEM_*".

Good point. I just took the naming from the original one. Especially if
all the logic is moved into Kconfig files, it has nothing to do with
DEFAULT what-so-ever. More of a VMSPLIT_3G or similar..

Linus
-
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/

Linus Torvalds wrote:

>On Tue, 10 Jan 2006, Martin Bligh wrote:
>
>
>>The non-1GB-aligned ones need to be disbarred when PAE is on, I think.
>>
>>
>
>Well, right now _all_ the non-3:1 cases need to be disbarred. I think we
>depend on the kernel mapping only ever being the _one_ last entry in the
>top-level page table, which is only true with the 3:1 mapping.
>
>But I didn't check.
>
>


No. It works fine (or seems to) with 2:2 mapping. I've tested with these
extensively
and am shipping products on the 1U appliances with 2:2 and I have never
seen any problems
with 2.6.9-2.6.13.

The only unpleasant side affect with 3:1 is user apps seem to rely on
swap space
a little more than I like -- perhaps this is the side affect you are
referring to?

RH ES uses 4:4 which is ideal and superior to this hack.

Jeff

> Linus
>-
>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/
>
>
>

-
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/

Jeff V. Merkey wrote:

> Linus Torvalds wrote:
>
>> On Tue, 10 Jan 2006, Martin Bligh wrote:
>>
>>
>>> The non-1GB-aligned ones need to be disbarred when PAE is on, I think.
>>>
>>
>> Well, right now _all_ the non-3:1 cases need to be disbarred. I think
>> we depend on the kernel mapping only ever being the _one_ last entry
>> in the top-level page table, which is only true with the 3:1 mapping.
>>
>> But I didn't check.
>>
>>
>
>
> No. It works fine (or seems to) with 2:2 mapping. I've tested with
> these extensively
> and am shipping products on the 1U appliances with 2:2 and I have
> never seen any problems
> with 2.6.9-2.6.13.
>
> The only unpleasant side affect with 3:1 is user apps seem to rely on
> swap space
> a little more than I like -- perhaps this is the side affect you are
> referring to?
>
> RH ES uses 4:4 which is ideal and superior to this hack.
>
> Jeff
>
Take that back. I checked the build and 2:2 does not work correctly with
highmem enabled. So
you may be correct. Highmem support is crap anyway and a 4:4 scheme is
what this should have been
from the start. It's ok. The nice thing about Linux if you don't like
what Linus is cooking in the kitchen,
you can add your own ingredients and make something else.

Jeff
-
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/

So, the patch would now look like this:


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
+ 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 0xC0000000
+ default 0xB0000000 if VMSPLIT_3G_OPT
+ default 0x78000000 if VMSPLIT_2G
+ default 0x40000000 if VMSPLIT_1G
+
config HIGHMEM
bool
depends on HIGHMEM64G || HIGHMEM4G
diff -u --recursive --new-file --exclude='.*' linux-2.6.15/arch/i386/mm/init.c linux/arch/i386/mm/init.c
--- linux-2.6.15/arch/i386/mm/init.c 2006-01-02 22:21:10.000000000 -0500
+++ linux/arch/i386/mm/init.c 2006-01-10 12:06:10.000000000 -0500
@@ -597,6 +597,12 @@
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE - 1) + 1;
#endif

+#if !defined(CONFIG_VMSPLIT_3G)
+ /* if the user has less than 960MB of RAM, he should use the default */
+ if (max_low_pfn < (960 * 1024 * 1024 / PAGE_SIZE))
+ printk(KERN_INFO "Memory: less than 960MiB of RAM, you should use the default memory split setting\n");
+#endif
+
/* this will put all low memory onto the freelists */
totalram_pages += free_all_bootmem();

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/

On Tue, 10 Jan 2006 15:39:31 +0100 Jens Axboe wrote:

> --- a/include/asm-i386/page.h
> +++ b/include/asm-i386/page.h
> @@ -109,11 +109,23 @@ extern int page_is_ram(unsigned long pag
>
> #endif /* __ASSEMBLY__ */
>
> +#if defined(CONFIG_DEFAULT_3G)
> +#define __PAGE_OFFSET_RAW (0xC0000000)
> +#elif defined(CONFIG_DEFAULT_3G_OPT)
> +#define __PAGE_OFFSET_RAW (0xB0000000)
> +#elif defined(CONFIG_DEFAULT_2G)
> +#define __PAGE_OFFSET_RAW (0x78000000)
> +#elif defined(CONFIG_DEFAULT_1G)
> +#define __PAGE_OFFSET_RAW (0x40000000)
> +#else
> +#error "Bad user/kernel offset"
> +#endif
> +
> #ifdef __ASSEMBLY__
> -#define __PAGE_OFFSET (0xC0000000)
> +#define __PAGE_OFFSET __PAGE_OFFSET_RAW
> #define __PHYSICAL_START CONFIG_PHYSICAL_START
> #else
> -#define __PAGE_OFFSET (0xC0000000UL)
> +#define __PAGE_OFFSET ((unsigned long)__PAGE_OFFSET_RAW)
> #define __PHYSICAL_START ((unsigned long)CONFIG_PHYSICAL_START)
> #endif
> #define __KERNEL_START (__PAGE_OFFSET + __PHYSICAL_START)

Changing PAGE_OFFSET this way would break at least Valgrind (the latest
release 3.1.0 by default is statically linked at address 0xb0000000, and
PIE support does not seem to be present in that release). I remember
that similar changes were also breaking Lisp implementations (cmucl,
sbcl), however, I am not really sure about this.

Jens Axboe wrote:

>On Tue, Jan 10 2006, Jeff V. Merkey wrote:
>
>
>>RH ES uses 4:4 which is ideal and superior to this hack.
>>
>>
>
>This isn't a hack, it's just making the offset configurable so you can
>get the best of what you want.
>
>And 4:4 may be ideal in a peyote haze, so whatever.
>
>

Jens,

You are just jealous because you can't take peyote. Next time your are
in Utah visiting Novell, come by Lindon at
the old keylabs building -- I'm on the second floor. I am right next
door to SCO (you can throw a rock and hit darls window from the parking
lot).
I don't ever talk to them and we have nothing to do with them.

Jeff

"Cry me a river(tm)" is an unregistered common law trademark of Linux
Torvalds.

:-)



-
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/

On Tue, 10 Jan 2006, Mark Lord wrote:
>
> So, the patch would now look like this:

Yes, except I think we need to make the "depends on" include !X86_PAE:

> +choice
> + depends on EXPERIMENTAL

depends on EXPERIMENTAL && !X86_PAE

since PAE depends on the 3G/1G split (we could make it work for a pure
2G/2G split, but that's a separate issue, and then we'd need to change the
CONFIG_PAGE_OFFSET defaults to be something like

default 0x80000000 if VMSPLIT_2G && X86_PAE

(but that's definitely not appropriate for now - that's a separate issue,
after somebody has verified that PAE and 2G:2G works)

Also, I think the arch/i386/mm/init.c snippet should just be removed. If
we make the split configurable, I don't see that we should warn about a
configuration where you have less memory than the point where the split
makes sense. A distribution (either something like Fedora _or_ just a
internal company "standard image") migth decide to use 2G:2G, but not all
machines might have lots of memory. Warning about it would be silly.

Anyway, this should go into -mm, and I'd rather have it stay there for a
while. I've got tons of stuff for 2.6.16 already, I'd prefer to not see
this kind of thing too..

Linus
-
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/

On Tue, Jan 10 2006, Mark Lord wrote:
> So, the patch would now look like this:

Looks good to me!

--
Jens Axboe

-
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/

Jens Axboe wrote:
> On Tue, Jan 10 2006, Mark Lord wrote:
>>So, the patch would now look like this:
> Looks good to me!

I'm just trying to save you some diff'ing, Jens!

Here it is again, with Linus's latest.

Andrew: please drop this into -mm for now, per Linus:

Chief Penguin wrote:
>Anyway, this should go into -mm, and I'd rather have it stay there for a
>while. I've got tons of stuff for 2.6.16 already, I'd prefer to not see
>this kind of thing too..

Signed-off-by: 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 0xC0000000
+ default 0xB0000000 if VMSPLIT_3G_OPT
+ default 0x78000000 if VMSPLIT_2G
+ default 0x40000000 if VMSPLIT_1G
+
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/