Date: Fri, 9 Nov 2001 11:17:49 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: Peter Wemm <peter@wemm.org>, ia64@FreeBSD.ORG Subject: Re: Region usage Message-ID: <20011109111749.B15768@kayak.xcllnt.net> In-Reply-To: <Pine.BSF.4.33.0111091135320.89493-100000@herring.nlsystems.com> References: <20011108114802.B13009@kayak.xcllnt.net> <Pine.BSF.4.33.0111091135320.89493-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 09, 2001 at 11:43:46AM +0000, Doug Rabson wrote: > > > > Put differently: user space should not know about regions, right? > > I'm not so sure. Out VM system certainly does cope with sharing parts of > address spaces and this happens a lot for e.g. shared libraries. The point > is that there is an associated cost - each address space needs PTEs and > pv_entries to record the foward and backward mappings respectively. If a > large object is being shared between a large number of processes, this > cost can actually be larger than the size of the object itself. Sharing at > the region level, in theory, can be nearly free since all the sharers > would be able to share PTEs, pv_entries and TLBs for the region. I see. It's not something we need to be functional complete, it's something we may want to do (or at least consider) in order to make it more efficient. Hmmm... If there's a large web of processes, each sharing one or more parts from one or more other processes in the web, then it's possible to exhaust the number of available RRs (assuming no other means to limit the space within a region). For simple cases (two or more processes all sharing the same space), this works. But still; I don't think this all implies an a-priori knowledge of regions, which is good... > Well if we fix the current problems with mmap not understanding about > limitations in the number of bits in the VA, mmap with an unspecified > address should be able to overflow into new regions as and when it needs > new address space. Yes. > > The second case is clearly unwanted. I'm not sure I like the first > > case as well, because it definitely means an incompatibility with > > the GNU toolchain, unless the options are already there. > > As far as I can see its just a case of changing a couple of constants at > ld(1) build time. Its important to remember that this won't affect loading > and running of binaries linked according to the linux standard layout. My > opinion is that default section layout is an OS-specific optimisation and > we should be able to tune for our own needs. Changing a couple of constants is clearly ok. I was worried about having actual code changes to support our model (including options to control the behaviour). That would mean local changes to the GC toolchain with all the maintenance overhead involved... -- 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?20011109111749.B15768>