Date: Fri, 19 Oct 2001 12:01:50 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Doug Rabson <dfr@FreeBSD.org> Cc: <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/ia64/include pmap.h src/sys/ia64/ia64 pmap.c Message-ID: <Pine.BSF.4.33.0110191149160.86695-100000@herring.nlsystems.com> In-Reply-To: <200110190947.f9J9l3g22142@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Oct 2001, Doug Rabson wrote: > dfr 2001/10/19 02:47:03 PDT > > Modified files: > sys/ia64/include pmap.h > sys/ia64/ia64 pmap.c > Log: > Rework pmap so that it separates the PTE structure from the pv_entry > structure. This makes it possible to pre-allocate PTEs for the kernel, > which is necessary for a reliable implementation of pmap_kenter(). This > also avoids wasting space (about 48 bytes per page) for kernel mappings > and user mappings of memory-mapped devices. > > This also fixes a bug with the previous version where the implementation > required the pv_entry structure to be physically contiguous but did not > enforce this (the structure size was not a power of two). This meant > that the pv_entry free list was quickly corrupted as soon as the system > was even mildly loaded. This version uses a shared pool to allocate PTEs for all user processes. There are some problems with this for un-managed mappings (i.e. mmap on a device). Particularly, it is difficult to keep track of all the PTEs used by a process for un-managed mappings and this implementation will leak PTEs (and active entries in the VHPT, which is worse) in this case. I have been thinking of allocating PTEs from a per-process pool but this still doesn't make it easy to track down all the mappings made in a process (the pv_entry structure does this for managed mappings). We need to do this so that we can remove the mappings from the VHPT on e.g. process exit. One possibility is to use pseudo page-tables for user mappings. A given page in the 'page table' would cover mappings for a particular range of virtual addresses (an 8k page would hold 256 PTEs). We would have to iterate over these page tables to identify and remove the un-managed mappings. Still ugly. Perhaps the only workable approach is to use something similar to pv_entry to keep a list of all unmanaged mappings in a process so that they can be explicitly removed. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.33.0110191149160.86695-100000>