Re: 2G memory split

From: Jens Axboe
Date: Tue Jan 10 2006 - 08:34:08 EST


On Tue, Jan 10 2006, Ingo Molnar wrote:
>
> * Jens Axboe <axboe@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/