jlol@REMUS.EE.BYU.EDU (Jay Lawlor) (02/01/91)
After much work spent trying to get a large code to run on an IBM RS/6000, we finally were told that it is a segmented machine and each process can only have a data segment of 256 MB minus the stack segment size. The 'workaround' is that you can allocate up to ten shared memory segments (256 MB each) and attach them to your process. Unfortunately, this code is written in fortran and allocates about 300 MB of static arrays for computation of 3D gaseous combustion simulation. It would not be particularly convenient to use shared memory segments in fortran. This code could (and probably should) use some kind of a block solver so it wouldn't need so much memory. Someday it probably will have to use a block solver. Meanwhile, I just know barely enough about the code to run it as a benchmark in some evaluations we are doing. Anyway, what we're wondering is whether other 'super workstations' like the new MIPS server, HP's soon to be announced "snake" line, etc. are going to have similar limitations. It seems like IBM has pulled another "nobody will ever need more than 64k segments" trick on us. Anyone care to comment on what limitations various machines have? Thanks
brandis@inf.ethz.ch (Marc Brandis) (02/01/91)
In article <9101312359.AA07832@ucbvax.Berkeley.EDU> jlol@ee.byu.edu writes: >After much work spent trying to get a large code to run on an IBM >RS/6000, we finally were told that it is a segmented machine and each >process can only have a data segment of 256 MB minus the stack segment >size. The 'workaround' is that you can allocate up to ten shared memory >segments (256 MB each) and attach them to your process. > >Anyway, what we're wondering is whether other 'super workstations' >like the new MIPS server, HP's soon to be announced "snake" line, etc. >are going to have similar limitations. It seems like IBM has pulled >another "nobody will ever need more than 64k segments" trick on us. > The limitation that your data segment cannot be larger than 256M is not built into the machine but into AIX. Actually, by providing this kind of segmentation IBM allows to break the 32-bit addressing barrier and opens up a 52-bit virtual address space. In "RISC System/6000 Processor Architecture" (IBM RISC System/6000 Technology, p. 20) Groves and Oehler write: The most significant four bits of each 32-bit effective address are used to select one of 16 segment registers. Each of these segment registers can be assigned to memory or I/O space determined by a bit in each segment register ... ... the least significant 24 bits of the segment register (the segment ID) are concatenated with remaining 28 bits of the effective address to create the 52 bit virtual address. So, if IBM really feels the need to have more than 256 MBytes of data which is not shared, they can remove this restriction with a new OS release. In the HP Precision Architecture, a similar approach is used to extent the addressing space beyond 32 bits while still using 32-bit addresses. There, the segments are 1 Gigabyte large. I do not know whether their OS does not allow to allocate static data larger than one segment. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
jfc@athena.mit.edu (John F Carr) (02/04/91)
In article <4bec_ne00asV81Rls1@andrew.cmu.edu> zs01+@andrew.cmu.edu (Zalman Stern) writes: >Of course you would think that >by now hardware designers would get the message that portable OS'es do not >use segmentation hardware and hence putting it on the chip is a waste. This is only true if the intent is for "portable OS'es" to run on the hardware. In the case of the RS/6000, IBM runs their own version of UNIX which takes advantage of segments. They don't care much for other operating systems. The BSD port to the RT also makes some use of memory segments, though not as much as it could. I don't know about AIX on the RT. Until object sizes exceed the segment size or the number of shared memory segments and memory mapped files used by a process exceeds the number of segments, I think a segmented architecture like the RT and RS/6000 has advantages for UNIX. When something changes you only need to update page tables for the segment, instead of for each process that uses the segment. Mapping an object into a new address space only requires changing one segment register instead of many page table entries. One could make the argument that a portable OS should not require any specific type of MMU. Some part of any operating system is machine dependent; you can define "portable OS" in any way you like depending on how much code you allow to be machine dependent. Back to the original topic: Since IBM is targeting supercomputer users with the RS/6000, I am surprised that the operating system is unable to handle very large data sizes. I think AIX should be blamed for this, not the hardware. I heard from an AIX developer last spring that a similar problem with large files was handled by AIX (a file > 256 MB, when memory mapped, is mapped to adjacent segments so it appears as a contiguous block), so I assume that the data segment limit is an oversight. -- John Carr (jfc@athena.mit.edu)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (02/05/91)
A portable o/s should not require fancy hardware, nor should it preclude the use of it. Machines with segments can make good use of them to memory map files, when the address space in one segment is not large enough. 32 bit addresses are not big enough when you try memory mapping a bunch of files. Segments are one solution to the problem. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez
cprice@mips.COM (Charlie Price) (02/05/91)
In article <9101312359.AA07832@ucbvax.Berkeley.EDU> jlol@ee.byu.edu writes: >process can only have a data segment of 256 MB minus the stack segment > >Anyway, what we're wondering is whether other 'super workstations' >like the new MIPS server, HP's soon to be announced "snake" line, etc. >are going to have similar limitations. > >Anyone care to comment on what limitations various machines have? The MIPS R2000, R3000, and R6000 all provide a 2 GByte linear virtual address space for user programs. This is 1/2 of the total 2^32 (4 GByte) virtual address space; the other half is reserved for kernel mode accesses. The other feature here is what the OS does for (or to) you. Most systems have some administrative limits on process size. The MIPS OS, RISC/os, has a "maximum size of user process" parameter that is specified at kernel build (link) time. Each system release comes with binaries that allow a site to change this parameter and build a new kernel. MIPS just announced information about the forthcoming R4000. The R4000 *architecture* has 64-bit integer registers and a total *architectural* virtual space for all processor modes of 2^64 bytes. Some fraction of that is available to user-mode programs. I can't provide details until the actual R4000 *product* announcement, but the R4000 will provide a significantly larger usable virtual space than the R[236]000 for user programs. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650
huck@aspen.IAG.HP.COM (Jerry Huck) (02/09/91)
>From: jlol@REMUS.EE.BYU.EDU (Jay Lawlor) >Anyway, what we're wondering is whether other 'super workstations' >like the new MIPS server, HP's soon to be announced "snake" line, etc. >are going to have similar limitations. It seems like IBM has pulled >another "nobody will ever need more than 64k segments" trick on us. > >Anyone care to comment on what limitations various machines have? PA-RISC machines have 32 bit offsets that can be used as 4 or less segments but that is a software convention. The current data size limitations are (like AIX) a function of the OS. On HP-UX, the current release limits the static data to something around 700Mbytes (with I imagine many caveats about swap space and system configuration). This restriction has nothing to do with "segments" rather it has to do with investment priorities. Shared data segments come from another 700-800Mb region. All of this is abstracted from the user and can be changed by subsequent releases of the OS. Another of HP's operating systems (MPE/XL), use the full 64 bit address space to support mapped files. In that environment, processes can address more than 2^32 bytes at a time. An important destinction from the RS6000 architecture is ability of the process, on PA-RISC, to address more than 2^32 bytes, using 64 bit pointers, without OS involvement. The only restriction is that address computations do not automatically carry out of the low 32 bits. Nothing prevents HP-UX or OSF based OS's from supporting 64-bit pointers. > This is very similar to what all sane UNIX >implementations do on the 80386 and 80486. Of course you would think that >by now hardware designers would get the message that portable OS'es do not >use segmentation hardware and hence putting it on the chip is a waste. >... >Zalman Stern, MIPS Computer Systems, 928 E. Arques 1-03, Sunnyvale, CA 94086 >zalman@mips.com OR {ames,decwrl,prls,pyramid}!mips!zalman (408) 524 8395 What do you mean here? Jerry Huck (huck@iag.hp.com) Hewlett-Packard Information Architecture Group
lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (02/10/91)
In article <1360007@aspen.IAG.HP.COM> huck@aspen.IAG.HP.COM (Jerry Huck) writes: [Zalman Stern, MIPS Computer Systems,writes:] >>Of course you would think that >>by now hardware designers would get the message that portable OS'es do not >>use segmentation hardware and hence putting it on the chip is a waste. > >What do you mean here? I think he means that the IBM RS6000 and the HP-PA would have been better architectures if they had just gone with flat 32-bit address spaces, and left off the segmentation features. I agree with him. As far as I can tell, the resulting systems aren't noticeably better than systems using 32 bits + good software. If marketing phrases such as "52 bit address" or "64 bit address" promise something extra - power, or software simplicity - then these segmentation schemes don't really deliver. -- Don D.C.Lindsay .. temporarily at Carnegie Mellon Robotics