Date: Fri, 9 Nov 2001 11:43:46 +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: <Pine.BSF.4.33.0111091135320.89493-100000@herring.nlsystems.com> In-Reply-To: <20011108114802.B13009@kayak.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Nov 2001, Marcel Moolenaar wrote: > On Thu, Nov 08, 2001 at 11:28:17AM +0000, Doug Rabson wrote: > > > > True. I can just about imagine an ILP32 app wanting to share address > > spaces with other apps but it seems unlikely. > > But isn't that the task of our VM subsystem and doesn't it already > handle it? > > 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 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. > > > > > > The question is if this can be done automagically or if it requires > > > compile-time options or even ELF object tuning (ie flags). > > > > This would happen automatically. If the elf sections were rooted in > > specific regions, the loader would automatically put them there and the VM > > system would allocate spaces as required. If a running app wants to use a > > new region, its as simple as giving an explicit address to mmap(2). > > Both cases are not automagically. To have the segments rooted in a > specific region, I probably need to tell the linker to arrange for > that. This means compile/link time visible differences. In the second > case it's even a programmer visible difference. 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. The linker currently has a builtin set of linker scripts which perform the current layout of sections. Supplying a different linker script is pretty easy though. > > 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. > > If, on the other hand, our loader would size the segments and > create either a single region address space or a multi-region > address space based on some heuristics, then that would qualify > as automagically. It would handle the "large" application case > without any visible differences... I think this is the ideal case. I don't think ld(1) is currently smart enough to understand the holes in the address space caused by unimplemented address bits but I imagine that could be fixed. -- 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?Pine.BSF.4.33.0111091135320.89493-100000>