Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!caip!nike!oliveb!glacier!mips!reuel From: reuel@mips.UUCP (Reuel Nash) Newsgroups: net.arch Subject: Re: Very large memories Message-ID: <689@mips.UUCP> Date: Sat, 13-Sep-86 22:49:23 EDT Article-I.D.: mips.689 Posted: Sat Sep 13 22:49:23 1986 Date-Received: Sun, 14-Sep-86 20:18:35 EDT References: <1164@ncr-sd.UUCP> <2383@peora.UUCP> Reply-To: reuel@mips.UUCP (Reuel Nash) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 38 In article <2383@peora.UUCP> joel@peora.UUCP (Joel Upchurch) writes: > > Another consideration, is that on at least some virtual > memory systems I've worked with, the the system transfers > the program over to some sort of paging file, before it > starts, which means that you end up reading the whole > program in anyway, and writing it out to boot. Does anyone > know of a virtual memory system that doesn't work this > way? > Yes! AT&T UNIX System V (at least the demand paging versions). In the default case (413 magic number -- demand loaded file & no sticky-bit set) System V demand-pages the program directly from the file system. Text (code) pages and unmodified data pages never get written to any paging device. Of course, one reason for all this is that this system runs on 3b2 computers with small disks and this scheme reduces the amount of swap space required. System V also effectively uses all available main memory pages as a cache for the text and data pages on disk (separate from the file system buffer cache). This means, for example, that on a large single-user workstation, when you compile a program the first time the compiler must be loaded from the disk. But, if you edit and re-compile, the compiler's pages are still in memory and will be re-used without going to the disk. Reuel Nash MIPS Computer Systems, Inc. 930 E. Arques Sunnyvale, CA 94086 408-720-1700 x244 decwrl!mips!reuel #include