Date: Wed, 7 Nov 2001 10:13:48 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Peter Wemm <peter@wemm.org>, <ia64@FreeBSD.ORG> Subject: Re: Region usage Message-ID: <20011107100741.Y549-100000@salmon.nlsystems.com> In-Reply-To: <20011107014307.A12510@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Nov 2001, Marcel Moolenaar wrote: > 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) Clearly IA-32 applications are limited to using R0. IA-64 32bit applications are more flexible though. There is a choice of zero-extension (i.e. R0 only), sign extension (i.e. R0 or R7) or 'pointer swizzling' which uses the top two bits of the 32bit address as a region number. This allows access to (the initial segment of) regions R0, R1, R2 and R3. I don't want to nail down usage of user-space regions unless we have to. The one possible exception to this is to try to support a 4k page size for IA-32 applications. This would be quite difficult with our VM system since it has no way of supporting variant page sizes. The Linux folks have been quite successful using the system page size and painting over the cracks for such things as non-aligned mmap calls. > > 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. Right. > > 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. A truly 'large' application can always overflow into the other regions. > > I'll double-check the various ia64 conventions tomorrow to see > how the above fits in. Thanks. -- 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?20011107100741.Y549-100000>