Date: Mon, 30 Jun 2008 11:56:35 -0500 From: Alan Cox <alc@cs.rice.edu> To: Ed Schouten <ed@80386.nl> Cc: Alan Cox <alc@freebsd.org>, cvs-src@freebsd.org, src-committers@freebsd.org, Ruslan Ermilov <ru@FreeBSD.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/include pmap.h Message-ID: <48691043.3080403@cs.rice.edu> In-Reply-To: <20080629215657.GI14567@hoeg.nl> References: <200806291835.m5TIZNLx089927@repoman.freebsd.org> <20080629211316.GA20319@edoofus.dev.vega.ru> <20080629215657.GI14567@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Ed Schouten wrote: >Alan, > >* Ruslan Ermilov <ru@FreeBSD.org> wrote: > > >>Can you please draw a new layout, similar to the one made by Peter? >> >>http://lists.freebsd.org/pipermail/freebsd-amd64/2005-July/005578.html >> >> > >I'm not familiar with the design of amd64 or its page tables, but is >there some kind of overhead when all 512 GB's would be allocated as kva? > > Yes, it would consume a rather large amount of (physical) memory. Roughly speaking, we preallocate memory for the page table that implements the kernel's address space. In other words, mapping a page into the kernel's address space never requires the allocation of (page table) memory, and unmapping a page never frees memory. This has some benefits, e.g., we will never block while mapping physical memory into the kernel's address space, and we can use a very simple, very fast method for mapping part of a file into the buffer cache. In general, that is, on most machine architectures, we can use a very simple technique to avoid preallocating page table memory that can't possibly be used. However, on amd64, the need to have kernel code and global/static variables in the highest 2GB of the kernel's address space undermines the effectiveness of that technique. So, it is still impractical to make the amd64 kernel address space arbitrarily large, as in 512GB. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48691043.3080403>