Yonghong Yan wrote: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? Afaik FreeBSD maps code+data as 4Kibyte pages first, then remaps the PD entries as 2Mibyte pages covering the same memory. 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). 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. Abstracting from the horror which is paging on IA32 (and derived) processors would be nice :). Cheers, -- Thomas E. Spanjaard tgen@netphreax.net
| Andy Whitcroft | Re: 2.6.23-rc6-mm1 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Alan | Re: [RFC] Heads up on sys_fallocate() |
git: | |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
