Date: Wed, 7 Nov 2001 01:43:08 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Peter Wemm <peter@wemm.org> Cc: Doug Rabson <dfr@nlsystems.com>, ia64@FreeBSD.ORG Subject: Re: Region usage Message-ID: <20011107014307.A12510@dhcp01.pn.xcllnt.net> In-Reply-To: <20011106213623.4A56439F0@overcee.netplex.com.au> References: <Pine.BSF.4.33.0111061712520.79195-100000@herring.nlsystems.com> <20011106213623.4A56439F0@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 06, 2001 at 01:36:23PM -0800, Peter Wemm wrote: > Doug Rabson wrote: > > > 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? > > For what its worth, we probably could put the stack in the top end of the > data segment region. I dont recall what granularity execute attributes > run at.. are they per-region or per-page? Per-page. I gave it some thought and I think we should not fill all RRs as Linux has. I'd like to have some space left in that area. A good seperation seems one based on page-size and scope. Something like: R0 - 32-bit applications; 4KB pages R1 - 64-bit applications; 8KB pages (or larger) R5 - VM; paged global; 8KB pages (or larger) R6 - uncached global; 256M pages; Id mapping R7 - cached global; 256M pages; Id mapping This leave R2, R3 and R4 unused for the moment. Possibilities (besides leaving them unused): o Reserve R2 for use by 64-bit applications so that R1 and R2 combined provide a 62-bit address space. o Reserve a region for SHM. Doug mentioned this as well. o Region for dynamic TLS (brainwave of mine) Since there might be unimplemented bits in the VA (and PA), combining text, data/heap and stack should work nicely, since both the heap and the stack grow toward the unimplemented address space. I see little advantage to have text, data/heap and stack be seperate regions, other than a nice side-effect while debugging (it's easy to see what an address references). The possibility of either of those segments taking up more than, say, 48 bits is very small ATM, although it's possible that I'm stuck in the a-couple-of-megabytes-is-large mindset and thus underestimate a typical "large" application. I'll double-check the various ia64 conventions tomorrow to see how the above fits in. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20011107014307.A12510>