Date: Thu, 14 Oct 1999 08:15:04 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <199910141515.IAA35743@pau-amma.whistle.com> In-Reply-To: <447.939897820@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Thu, 14 Oct 1999 12:43:40 +0200 >From: Poul-Henning Kamp <phk@critter.freebsd.dk> [I probably should have changed the Subject:.... dhw] >Using mmap(2) to provide a new type of buffered semantics for >disk-like devices is insteresting, but its applicability will be >limited by the virtual address space of a process: you can't map >a 20GB database into a 32bit address space, so a lot of mmap(2) >calls will be needed for serious sized data. The need for, and >actual use of such a facility seemes uncertain. For whatever it might possibly be worth, re: the issue of addressing more storage than the address space, I'll briefly sketch what I recall of what IBM (the mainframe side of the house) did in the transition from MVS/XA -> MVS/ESA. The purpose is illustration, not advocacy (either pro or con). :-) The hardware in question uses 32-bit words, but in MVS/XA, they used 31-bit addresses. (High-order bit was reserved. I don't *even* want to think about that....) System architecture tended to reserve a very large chunk of address space for system (common to each AS) information. Over time, this tended to grow, decreasing the private area of the AS. Meanwhile, applications such as databases needed to access more data, and their architects wanted to keep the data resident... and if you do that, it really helps if it's addressable. :-) So IBM came up with an "interesting" concept... "data only" address spaces: A program would run in one address space, and request that the OS create a new address space for it to play in. The (first -- don't recall the official term) AS would then denote a range within this new AS, and cause data to be placed into it. This (data-only AS creation & access) could happen for up to some architectural limit of data-only ASs per "normal" AS. A database engine could, for example, place separate tables in separate data-only ASs. It should be noted that paging I/O was measurably faster than normal I/O, generally. And it was possible (with sufficient chilled water) to put a *lot* of memory on these beasts. So if, at some point, accessing more VM than one AS becomes an issue, that's the basics of one approach that has been used. Should we get to that point, I'd hope we can learn from others' experiences. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910141515.IAA35743>