Date: Wed, 7 Nov 2001 12:52:20 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: <ia64@FreeBSD.ORG> Subject: Re: Region usage Message-ID: <Pine.BSF.4.33.0111071238340.83203-100000@herring.nlsystems.com> In-Reply-To: <20011106203044.A569@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Nov 2001, Marcel Moolenaar wrote: > There's one thing we definitely must do: use the PID for the RID > to avoid TLB flushes... On the subject of avoiding TLB flushes, its quite hard to do in practice. When an address space is being torn down for execve, the VM system makes a sequence of calls to pmap_remove() to delete all the old mappings but the pmap layer has no idea what is really happening. If pmap knew that an execve was going on, it could avoid the TLB flush (it would still need to remove entries from the VHPT) and simply assign a new RID after the last mapping was removed. The TLB flush could then be deferred until the old RID was reused. Currently, the VHPT contains complete mapping information for all address spaces via the collision chains. An alternative model would be to record the mappings for an individual address space seperately, e.g. in software-managed page tables. We could then treat the VHPT as a simple cache (i.e. ignoring the collision chains) and handle TLB faults by traversing the software page tables. This would allow us to defer removing mappings from the VHPT by simply assigning a new RID to the address space. It would also make it possible to support more address spaces than the number of supported RIDs. The alpha pmap does this by sequentially allocating ASNs (the equivalent of RIDs) and flushing the TLB when the ASN wraps. For ia64 we would flush both the TLB and the VHPT. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" 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.0111071238340.83203-100000>