Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE

[joe Shmoe <jsmoe3@yahoo.com>]

Hey Alan,
May be I confused you. Sorry

> 0-3GB        MMU translations
> to arbitary basically random
> physical addresses (with many pages shared and some
> absent)

Can those "arbitary basically random physical addresses" fall outside 
1GB-3GB is my question. Why does kernel stop at 896MB during page table setup. Why not go ahead and map the remaining available RAM (where RAM size is > 1GB < 4GB)
But kernel uses different technique for addressing the high memory > 896MB

Not sure this is being done so that it will be easier for kernel to maintain page table assignments/swaping to various processes.
 
> 3GB+        Physical mapping
> only accessible in kernel mode

Yes. This part I understand obviously these addresses are issued only when a process is running in kernel mode.


--- On Fri, 8/28/09, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Subject: Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE
> To: "joe Shmoe" <jsmoe3@yahoo.com>
> Cc: linux-kernel@vger.kernel.org
> Date: Friday, August 28, 2009, 6:16 PM
> O> I understand the implications
> of reloading CR3. But once the page tables are  setup
> to map all the available physical RAM to virtual (linear)
> address it could be for eg. 1, 2, 3 or 4 GB how does it
> matter.
> 
> Where are you putting the user virtual addresses. User
> addresses don't
> map direct to physical addresses so you need both sets of
> translations at
> once
> 
> Right now you have
> 
> 0-3GB        MMU translations
> to arbitary basically random
> physical addresses (with many pages shared and some
> absent)
> 
> 3GB+        Physical mapping
> only accessible in kernel mode
> 
> If user applications ran with a 1:1 mapping of application
> space to
> physical addresses you would be fine - but they don't and
> it would be
> rather hard to run like that because you want page sharing,
> lazy unshare,
> vfork etc to all work.
>