Date: Tue, 3 Apr 2012 14:52:19 -0400 From: vasanth rao naik sabavat <vasanth.raonaik@gmail.com> To: Mark Tinguely <marktinguely@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: question about amd64 pagetable page allocation. Message-ID: <CAAuizBgAPu9n=gAubVZXxdyboaH1BT_sxQu-jAJB1QSpbn%2BO4g@mail.gmail.com> In-Reply-To: <CAP%2BM-_E%2BwsDRPd6JiO4M-MEsYERnGcA-oR-ckWAeEE7kWwrfmw@mail.gmail.com> References: <CAAuizBhUuWvbYjZewO5LgHPuGfi37mW0sJFAKs-YN-G1ZbNAUQ@mail.gmail.com> <CAP%2BM-_Es5A3a0%2BcM6K=qi_kbk0ftnHHmZoazuerhg3TxrVr6SA@mail.gmail.com> <CAAuizBh0M_wpUvWU%2B0-CMC9XveqQNXOqtB92NhABnGGUVuq4DQ@mail.gmail.com> <CAP%2BM-_E%2BwsDRPd6JiO4M-MEsYERnGcA-oR-ckWAeEE7kWwrfmw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Mark,
I think pmap_remove_pages() is executed only for the current process.
2549 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY
2550 if (pmap != vmspace_pmap(curthread->td_proc->p_vmspace)) {
2551 printf("warning: pmap_remove_pages called with non-current
pmap\n");
2552 return;
2553 }
2554 #endif
I dont still get it why this was removed?
Thanks,
Vasanth
On Tue, Apr 3, 2012 at 12:42 PM, Mark Tinguely <marktinguely@gmail.com>wrote:
> On Tue, Apr 3, 2012 at 10:18 AM, vasanth rao naik sabavat
> <vasanth.raonaik@gmail.com> wrote:
> > Hello Mark,
> >
> > Thank you for replying,
> >
> > Could you please point me to any document which illustrates the
> > implementation of recursive page tables in FreeBSD for amd64.
> >
> > Also, I just found that with the following patch from Alon, the usage of
> > vtopte() is removed in pmap_remove_pages(). Why was this removed?
> >
> > http://lists.freebsd.org/pipermail/svn-src-all/2009-March/006006.html
> >
> > Thanks,
> > Vasanth
> >
> > On Tue, Apr 3, 2012 at 10:56 AM, Mark Tinguely <marktinguely@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 3, 2012 at 8:33 AM, vasanth rao naik sabavat
> >> <vasanth.raonaik@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > I am trying to understand the page table page allocation for a process
> >> > in
> >> > FBSD6.1. I see that the page table pages are allocated by
> >> > vm_page_alloc().
> >> > I believe the virtual address for this allocated page can be derived
> by
> >> > PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)), however when I compare this address
> >> > with
> >> > the virtual address accessed in pmap_remove_pages() they are not the
> >> > same.
> >> >
> >> > The virtual address of a *PTE in pmap_remove_pages() is something like
> >> > *0xffff800000643200
> >> > *
> >> > However, the virtual address of the page allocated by vm_page_alloc()
> is
> >> > *
> >> > 0xffffff033c6a0000
> >> >
> >> > *I would also like to understand the importance of loc_PTmap, I
> believe
> >> > the
> >> > pmap_remove_pages() is derving the page table page addresses from
> >> > loc_PTmap?
> >> > (kgdb) p loc_PTmap
> >> > Cannot access memory at address 0xffff800000000000
> >> >
> >> > How do we relate the loc_PTmap to the page table pages allocated by
> >> > vm_page_alloc() in _pmap_allocpte().
> >> >
> >> > Thanks,
> >> > Vasanth
> >>
> >>
> >>
> >> The answer to your questions will be more obvious when you get an
> >> understanding of the Recursive Page Tables.
> >>
> >> --Mark Tinguely.
> >
> >
>
> Search for "recursive page tables" start with 32 bits first. I did not
> read it, but the below page looks promising:
>
>
> http://www.rohitab.com/discuss/topic/31139-tutorial-paging-memory-mapping-with-a-recursive-page-directory/
>
> The nice thing about recursive page table is the MMU does the work. But:
>
> 1) User recursive page tables work only for the current map.
> 2) Kernel mappings are placed at the top of every map - so the kernel
> recursive addresses will always be valid.
>
> As the comment in the link states, that change converted from using
> user recursive page table virtual address (which is only valid when
> the map is current) to using the physical to virtual direct map (which
> is always valid).
>
> --Mark Tinguely.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAuizBgAPu9n=gAubVZXxdyboaH1BT_sxQu-jAJB1QSpbn%2BO4g>