Date: Mon, 1 May 2006 15:10:25 -0700 From: Peter Wemm <peter@wemm.org> To: Suleiman Souhlal <ssouhlal@freebsd.org> Cc: src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <200605011510.26443.peter@wemm.org> In-Reply-To: <4453B5D5.4090206@FreeBSD.org> References: <200604281905.k3SJ59MZ008806@repoman.freebsd.org> <4453A429.5080406@root.org> <4453B5D5.4090206@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 29 April 2006 11:52, Suleiman Souhlal wrote: > Nate Lawson wrote: > > Peter Wemm wrote: > >> Stephan realized that the kernel already allocates one PTE per > >> virtual page. Although it normally holds physical addresses plus > >> attributes, as long as we don't set PG_V, then there are 31 other > >> bits that we could use for data storage. We could put virtual > >> addresses in there so long as we didn't set PG_V, and abuse that > >> to have a singly linked freelist threaded through the PTEs. It > >> turned out even easier though. As long as the virtual addresses > >> are page aligned, we neatly avoid all the PG_* mode bits as well. > > > > ... because you can shift by the page size, saving 12 bits. But > > are there any problems with 2 MB pages? > > It should work fine with 2/4MB pages too. Just like PTEs, when a PDE > (the 2/4MB entry) is marked as not present, all the bits but the > zeroth one are available for use to the operating system. On FreeBSD/i386, the page table pages are still present for kernel memory even when there is a 2/4MB page pointing over the top of it. We just need the slot in the page table page to ABuse. Since it isn't mapped, its contents are even more irrelevant to the cpu. -- 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?200605011510.26443.peter>