Yonghong Yan wrote:
quoted text
> 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?

quoted text
> 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.

quoted text
> 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).

quoted text
> 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.

quoted text
> 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