Date: Wed, 7 Nov 2001 10:07:29 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: <ia64@FreeBSD.ORG> Subject: Re: Region usage Message-ID: <20011107095132.R549-100000@salmon.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: > On Tue, Nov 06, 2001 at 05:33:00PM +0000, Doug Rabson wrote: > > As a quick intro for people new to the architecture, the ia64 VM system > > defines eight independent regions, selected by the top three bits of the > > virtual address. Each region is essentially a window onto a 61-bit unique > > address space - the address space which is mapped depends on the setting > > of the appropriate region register (one per region, of course). > > You can also think of it as a 85-bit virtual address space. Each region > selects a 61-bit window within that address space. > > > This is not necessarily the ideal way to manage virtual addresses on ia64. > > For one thing, there are a limited number of possible address spaces which > > can be supported concurrently (itanium allows 2^18, the maximum that any > > implementation will allow is 2^24). Also, the default configuration for > > ld(1) forces the use of two regions (one for text, one for data) and we > > use a third for stack. This is pretty wasteful and leaves only two > > regions free for address space sharing. > > > > I can't see any real benefit for using more than one region for most > > programs. I think that probably the text section should default to region > > zero, offset maxpagesize (pick a value for this, 64k?) with the data > > section following in the natural way and the stack starting at the end of > > region zero. Does anyone know why the GNU folks chose to put the data > > sections in a different region from the text sections? > > This is probably an HP heritage. PA-RISC has the same concept of > regions and given the history of ia64 it's logical to be in ia64. > HP-UX has the same layout, although their VM probably depends on > it more than Linux' or ours. I can't see any benefit for most applications and as I said before, special cases can still use the other regions for their own nefarious purposes. In fact, right now, the runtime linker places all the shared libraries in region 3 so we are already executing code in both regions. > > > Note that defaulting to this layout would not stop processes from using > > the rest of the address space if they need to - just mmap or whatever as > > needed. What it does do is free up as many regions as possible for > > application-specific address space sharing (e.g. Oracle). > > > > Comments? Ideas? > > I'll think about it. Let me read Peter's reply as well and collect > some info... > > There's one thing we definitely must do: use the PID for the RID > to avoid TLB flushes... I don't think we can do this, not simply anyway. There is no guarantee that the PID will fit into the range allowed for RIDs. Also we can need up to five distinct RIDs for some applications. I've been experimenting with different schemes for allocating RIDs. One problem with the existing model of sequential allocation (apart from the fact that it has no real protection for wrapping) is that we get far too many collisions in the VHPT. The RID is xor'ed into the VA to construct the VHPT address and if two processes only differ in one bit for a given RID, they will tend to use exactly the same set of VHPT entries. The best model I have so far is to use arc4random() to allocate RIDs and keep a bitmap of which RIDs are currently allocated. This reduces VHPT collisions significantly (although they are still much higher than I would like, even with very large VHPTs). -- 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?20011107095132.R549-100000>