Date: Sat, 29 Apr 2006 20:52:05 +0200 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, src-committers@freebsd.org, cvs-all@freebsd.org, Peter Wemm <peter@wemm.org>, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <4453B5D5.4090206@FreeBSD.org> In-Reply-To: <4453A429.5080406@root.org> References: <200604281905.k3SJ59MZ008806@repoman.freebsd.org> <20060429024850.GB997@turion.vk2pj.dyndns.org> <4452FB64.7030308@root.org> <200604291021.12379.peter@wemm.org> <4453A429.5080406@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Suleiman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4453B5D5.4090206>