Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!vrdxhq!BMS-AT!stuart From: stuart@BMS-AT.UUCP (Stuart D. Gathman) Newsgroups: net.unix-wizards Subject: Re: RAM disk vs paging + buffer cache Message-ID: <179@BMS-AT.UUCP> Date: Fri, 29-Aug-86 18:53:41 EDT Article-I.D.: BMS-AT.179 Posted: Fri Aug 29 18:53:41 1986 Date-Received: Fri, 29-Aug-86 23:27:05 EDT References: <514@opus.nbires.UUCP> <27300012@convex> Organization: Business Management Systems, Inc., Fairfax, VA Lines: 72 Summary: State of the art In article <27300012@convex>, watson@convex.UUCP writes: > Conceptually, I agree that it would be nice if the file system buffer > cache and paging system cache were one. You could have one set > of kernel I/O routines, instead of two. You could dynamically > use pages in the most optimal way, for file buffering, or text > buffering. The problem is that you introduce serious coupling The Mach kernel does exactly that! Files can be simply memory mapped and 'read' and 'write' emulated. I am tremendously impressed by the little I read in Unix Review concerning Mach/1 (partly because I had thought of all the stuff except the network transparency and threads years ago and couldn't get anyone interested in doing Unix 'right'). Mach creates a machine dependent layer that handles a) virtual memory b) tasks (like unix processes) c) threads (seperate CPU states within a task for closely coupled parallel processing). d) ports (like SysV message queues with only one receiver. Any size message can be sent. Big messages are handled by twiddling registers in the memory management hardware). e) device drivers The only basic operations are 'send' and 'receive' to ports! The messages (although arbitrary from the kernels point of view) contain headers and are typed so that data formats can be automatically translated when required. The ports in effect behave like objects in smalltalk. Memory is logically copied (for forks, messages, etc.) via "copy on write". The memory is simply mapped into a tasks address space as read only. When a write is attempted, an actual copy is made. 'pagein' and 'pageout' ports can be specified when allocating memory. This is how a file can be memory mapped and why programs don't have to be 'loaded' in the unix sense (which effectively copies the program data from the executable file to the swap area). Ports can be attached to file systems, network servers, SysV emulators, and whatever running in user state. You can page your virtual memory to a filesystem on a remote machine transparently! The network acts as one giant parallel machine. (This is the part I didn't see before.) The only non-transparent effect is that particular code and data will mean different things to different processors. (I.e. 68k code will not execute as desired on a 286). Because of the typing standard for messages, data can be automatically translated by the server for a different CPU. This means setting up a file system on a seperate CPU is trivial! This kernel is also more portable because the machine dependent portion is so small. To port your system (complete with SysV and Berkeley unix environments plus new parallel stuff), you need to change the compilers code generator to handle the CPU, change the kernel to handle the memory management, and change the device drivers to handle the I/O. Unix stuff like pipes, message queues, semaphores, sockets, streams, raw devices, you name it, can be emulated _efficiently_ and portably using 'ports'. These concepts require CPU's with a) large address spaces. (for memory mapped files, not strictly rqd) b) memory management with fault recovery. (for copy on write) 8-bits are out. 80286 would work, but segments complicate efficient code generation. 80386 is in. 68010, 68020 is in. 68000 is out (no page fault recovery). S/1 is out (no page fault recovery). The concepts in this system make the computer network envisioned in 'Tron' a practical reality. -- Stuart D. Gathman <..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>