Messages in this thread | | | Date | Sat, 29 Aug 2009 07:40:34 -0700 (PDT) | From | joe Shmoe <> | Subject | Re: kernel page table mapping for >1GB <3 GB for x86 arch without PAE |
| |
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. >
-- 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/
| |