William Lee Irwin III <[EMAIL PROTECTED]> writes: > On Tue, May 01, 2007 at 05:58:29AM +0200, Andi Kleen wrote: >> 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(-) > > What on earth? > > config PAGE_OFFSET > hex > default 0xB0000000 if VMSPLIT_3G_OPT > default 0x78000000 if VMSPLIT_2G > default 0x40000000 if VMSPLIT_1G > default 0xC0000000 > > This appears to have been introduced by: > commit 975b3d3d5b983eb60706d35f0d24cd19f6badabf > Author: Mark Lord <[EMAIL PROTECTED]> > Date: Wed Feb 1 03:06:11 2006 -0800 > [PATCH] VMSPLIT config options > > There's some sort of insanity going on here. Since when is 0x78000000 > a 2GB/2GB split? Mark, dare I ask what you were thinking? That should > be VMSPLIT_2G_OPT for 2GB laptops analogously to VMSPLIT_3G_OPT, if > nothing else, as it's certainly not 2GB/2GB.
It makes a little more sense when you realize all of the options were originally !X86_PAE. So they were designed with highmem disabled. > These VMSPLIT config options vs. PAE are foul as they're now done in > any event. If they were done properly, they'd properly set up the pmd > within which the division point between user and kernelspace falls. They were designed to avoid highmem a totally different design point. > This patch, I suppose, stops people from shooting themselves in the > foot, but (IMHO) the VMSPLIT patches shouldn't have been merged > without handling the partial pmd case. 2MB/4MB resolution is enough > granularity for any reasonable purpose, so split ptes aren't worth the > effort, but this nonsense with PAE vs. VMSPLIT is just preposterous. > If you're going to play the VMSPLIT game at all, handle split pmd's. What I find telling is that I fixed this based on code review not based on bug reports. > I'll see what else is pending in the i386 pagetable arena and clear > this up if there aren't other objections (this is where Andi gets to > complain that things are too complex already and preemptively NAK to > save me the effort, if it's not seen to be desirable). Eric, your patch > is a reasonable stop-gap measure for the original deficiency. Frankly rather then putting much effort into this I suspect we should just delete these options entirely. We are long past the point where they matter. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/