DragonFly kernel List (threaded) for 2007-10
DragonFly BSD
DragonFly kernel List (threaded) for 2007-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pmap of amd64


From: "Yonghong Yan" <noah.yan@xxxxxxxxx>
Date: Fri, 12 Oct 2007 17:20:52 -0600

yes, what is the recursive mapping and i canot find no where to point
to from google

On 10/12/07, Thomas E. Spanjaard <tgen@netphreax.net> wrote:
> Yonghong Yan wrote:
> > below is the amd64 long mode 4k page VA structure.
> >
> > 63           48             39               30              21
> >        12                 0
> > ----------------------------------------------------------------------------------------
> > |      Ext       |     PML4   |    PDP        |      PD      |      PT
> >        |     offset     |
> > ----------------------------------------------------------------------------------------
> >                            9it              9bit            9bit
> >      9bit             12bit
>
> I don't see it in this graph, but you do know you only (on current
> x86-64 processors) have 48bits of VA space, one half is on the top end
> of a true 64bit VA space, and the other half on the lower end?
>
> > some issues for discussions:
> >
> > 1. 4K page or 2M page for kernel?
>
> Afaik FreeBSD maps code+data as 4Kibyte pages first, then remaps the PD
> entries as 2Mibyte pages covering the same memory.
>
> > 2. how many PML4/PDP entry for kernel/user?
>
> You could dedicate the lower half of your PML4 table to user PDP tables,
> and the upper half to the kernel. There's also some crap with stupid
> recursive mappings or some shit to do (no, I don't like them).
>
> > 3. how to do with the per-cpu data, should a PML4/PDP entry for each CPU?
>
> A per-CPU PML4 entry would be wildly inefficient, also limiting the
> scalability of DragonFly/x86-64 on current CPUs to, say, 254 processors
> tops. As there's not a lot of per-CPU data pages, I think it's safe to
> go with the same number we have on pc32.
>
> > hopefully there are relevant. others issues that I may not know,
> > please raise them. answers to them may have do with the
> > machine-independent VM management and the specificities of dfly kernel
> > thread/messaging system.
>
> Abstracting from the horror which is paging on IA32 (and derived)
> processors would be nice :).
>
> Cheers,
> --
>          Thomas E. Spanjaard
>          tgen@netphreax.net
>
>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]