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.
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.
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.
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.
-- wli
William Lee Irwin III a ?crit :
> 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.
Please could you stop saying others are insane ?
They are like you and can fail sometime. Apparently when the patch came,
nobody (including you) commented.
It's not that difficult to think about VMALLOC space (I might be wrong about
this, but I feel this explains 78000000 vs 80000000)
>
> 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.
>
> 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.
>
> 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.
William Lee Irwin III a ?crit :
>> 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.
On Tue, May 01, 2007 at 06:57:19AM +0200, Eric Dumazet wrote:
> Please could you stop saying others are insane ?
> They are like you and can fail sometime. Apparently when the patch came,
> nobody (including you) commented.
> It's not that difficult to think about VMALLOC space (I might be wrong
> about this, but I feel this explains 78000000 vs 80000000)
I'm obviously aware of vmallocspace. Read carefully:
>> 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.
The meaning of "for laptops" is that it's carving out a chunk of
user virtualspace to use for vmallocspace in lieu of carving out a
piece of the 1:1 mapping of physical memory for the same purpose.
-- wli
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
William Lee Irwin III wrote:
> 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.
You need to go search the archives and read the *extensive* thread
on this from when it was introduced. Lots of high profile kernel
developers were in on this one.
The idea is really simple: eliminate the need for HIGHMEM
on common machines.
And yes, VMSPLIT_2G really means VMSPLIT_2G_OPT,
in the same way as the (added last) VMSPLIT_3G_OPT flag.
Cheers
William Lee Irwin III wrote:
>> 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.
On Tue, May 01, 2007 at 09:32:33AM -0400, Mark Lord wrote:
> You need to go search the archives and read the *extensive* thread
> on this from when it was introduced. Lots of high profile kernel
> developers were in on this one.
Various good points were raised. The NX bit requiring
3-level pagetables suggests that 3-level pagetables without highmem
would be valuable, at which point the unaligned splits to avoid highmem
with 3-level pagetables gain additional relevance. I'll queue that up
to be written along with split pmd affairs, and check for features
dependent on 4-level pagetables, too.
On Tue, May 01, 2007 at 09:32:33AM -0400, Mark Lord wrote:
> The idea is really simple: eliminate the need for HIGHMEM
> on common machines.
Of course. Everything is simple until it's done properly. It's
why everyone forgets the "and no simpler" half of the quote, which
turns the meaning of what everyone tries to quote on its head.
I guess looking over it I don't blame you so much. I should've been
around to clean up these issues at the time it was happening. People
seem to have been trying to use the RAM in their laptops without big
slowdowns, and may not have had the VM "sophistication" to deal with
the sorts of issues I'm raising.
On Tue, May 01, 2007 at 09:32:33AM -0400, Mark Lord wrote:
> And yes, VMSPLIT_2G really means VMSPLIT_2G_OPT,
> in the same way as the (added last) VMSPLIT_3G_OPT flag.
This was a large portion of the substance of my complaint.
-- wli
William Lee Irwin III wrote:
>..
> On Tue, May 01, 2007 at 09:32:33AM -0400, Mark Lord wrote:
>> You need to go search the archives and read the *extensive* thread
>> on this from when it was introduced. Lots of high profile kernel
>> developers were in on this one.
>
> Various good points were raised. The NX bit requiring
> 3-level pagetables suggests that 3-level pagetables without highmem
> would be valuable, at which point the unaligned splits to avoid highmem
> with 3-level pagetables gain additional relevance. I'll queue that up
> to be written along with split pmd affairs, and check for features
> dependent on 4-level pagetables, too.
Excellent! That would be super to have in there, William.
Cheers!