yes, what is the recursive mapping and i canot find no where to point to from google
On 10/12/07, Thomas E. Spanjaard <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > >
