From owner-freebsd-ia64 Wed Nov 7 4:53:42 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 28F1D37B416 for ; Wed, 7 Nov 2001 04:53:39 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 161SD2-0009m1-0Y; Wed, 7 Nov 2001 12:53:36 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id fA7CqK783554; Wed, 7 Nov 2001 12:52:20 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 7 Nov 2001 12:52:20 +0000 (GMT) From: Doug Rabson To: Marcel Moolenaar Cc: Subject: Re: Region usage In-Reply-To: <20011106203044.A569@dhcp01.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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