Date: Sun, 24 Jul 2005 10:47:52 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-amd64@freebsd.org Cc: Petri Helenius <pete@he.iki.fi> Subject: Re: kernel memory Message-ID: <200507241047.52669.peter@wemm.org> In-Reply-To: <42E33E67.7040205@he.iki.fi> References: <42DFDCCA.8050207@he.iki.fi> <42DFF043.3090203@he.iki.fi> <42E33E67.7040205@he.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 24 July 2005 12:08 am, Petri Helenius wrote: > BTW, I remember seeing a freebsd memory map somewhere but I'm unable > to locate it again. Is there one that has been updated to be valid > for the 64 bit platforms? 0000000000000000 - 00007fffffffffff userland 0000800000000000 - ffff7fffffffffff does not exist (hole) ffff800000000000 - ffff804020100fff recursive page table (512GB slot) .. unused .. ffffff0000000000 - ffffff7fffffffff 512GB direct map mappings ffffff8000000000 - ffffffff7fffffff 510GB future kva (todo) ffffffff80000000 - ffffffffffffffff 2GB kva This is specific to the FreeBSD/amd64 kernel as it currently stands. The "hole" does not exist, you can't generate addresses in that region because it doesn't map onto the page table tree and causes a GPF. This layout is arranged around the 512 entry 4th level page table page. Each slot corresponds to 512GB of virtual address space. Slots 0 - 255 are userland, 256 - 511 are kernel. kvm is using 2GB out of the topmost slot. When we extend KVM, it'll have all 512GB available. The direct map region uses the next slot from the top, using 2MB pages. It only has enough entries in there to cover max(physicalram, 4GB); because it is still a page table tree and it would consume physical pages to implement it. If there is nothing actually there, there isn't much point wasting page table pages for them. There is a huge "unused" block in the kernel half of address space. Only 3 of the 256 kernel slots are used. > Pete > > Petri Helenius wrote: > > Peter Wemm wrote: > >> 2GB for paged kernel memory. But in addition we access memory via > >> the direct map area to avoid the need for temporary mappings in > >> many cases. uma (malloc, mbufs) etc use this, as does the sfbuf > >> temporary mapping system. > > > > So there is no limitation for malloced memory? Say if my driver > > would like to have 4 or 8 gig lookup cache that would work? > > > > Pete > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507241047.52669.peter>