DragonFly kernel List (threaded) for 2007-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: pmap of amd64
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
Attachment:
signature.asc
Description: OpenPGP digital signature
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]