Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!bogstad From: bogstad@brl-smoke.ARPA (William Bogstad ) Newsgroups: net.arch Subject: Re: Very large memories (paging files) Message-ID: <3778@brl-smoke.ARPA> Date: Sat, 13-Sep-86 14:46:05 EDT Article-I.D.: brl-smok.3778 Posted: Sat Sep 13 14:46:05 1986 Date-Received: Sun, 14-Sep-86 07:35:01 EDT References: <1164@ncr-sd.UUCP> <2383@peora.UUCP> Reply-To: bogstad@brl.arpa (William Bogstad (JHU|mike) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 27 Keywords: paging, Ridge, ROS Summary: Some systems don't use them In article <2383@peora.UUCP> joel@peora.UUCP (Joel Upchurch) writes: [lines deleted ] > 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, it is my understanding that the Ridge 32 systems running ROS page directly from the executable file. The block size on disk is 4096 bytes and there is a way (although somewhat painful) to make files contiguous which avoids some of the obvious problems with disk access times. ROS looks like System V unix from the system call level, but internally is a message passing system consisting of multiple processes. All disk i/o goes through the virtual memory manager. When reading and writing a file you are in fact passing messages to a simple process whose data space is the contents of the file. Overall, this method doesn't work too badly. Bill Bogstad bogstad@hopkins-eecs-bravo.arpa bogstad@brl-smoke.arpa Disclaimer: I do not work for Ridge and have never done so. I am, however, the moderator for the ARPANET INFO-RIDGE mailing list.