Date: Tue, 06 Nov 2001 13:36:23 -0800 From: Peter Wemm <peter@wemm.org> To: Doug Rabson <dfr@nlsystems.com> Cc: ia64@FreeBSD.ORG Subject: Re: Region usage Message-ID: <20011106213623.4A56439F0@overcee.netplex.com.au> In-Reply-To: <Pine.BSF.4.33.0111061712520.79195-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? I believe the reason is that TLB's are supposedly tagged by region, and that if you have two processes using the same region for the text section, then they share the tlb's. A context switch between two processes using the same shared region for (say) text space means you get to avoid lots of flushing. Intel are funding a research project to add region awareness to Linux to make better use of this. This should be quite a lot of entertainment to fit it in the Linux VM system. 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? The register stack engine deflates most of the security implications of stack buffer overflows but it would still be nice to have a non-executable stack. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20011106213623.4A56439F0>