ralphw@ius2.cs.cmu.edu.UUCP (02/24/87)
I was wondering how difficult it might be to 'integrate' virtual memory
with the file system process. I'm told that the Multics operating system
mapped a file into the virtual address space when it was opened.
Would this be of any advantages (smaller code size, simpler semantics?)
in a Minix-based system?
--
- Ralph W. Hyre, Jr.
Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Radio: N3FGW (c/o W3VC, CMU Radio Club, Pittsburgh, PA)
(was KA3PLY, will probably change calls again if/when I get Advanced.)
--
- Ralph W. Hyre, Jr.
Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Radio: N3FGW (c/o W3VC, CMU Radio Club, Pittsburgh, PA)
(was KA3PLY, will probably change calls again if/when I get Advanced.)hays@apollo.UUCP (02/27/87)
In article <1057@ius2.cs.cmu.edu> ralphw@ius2.cs.cmu.edu (Ralph Hyre) writes: >I was wondering how difficult it might be to 'integrate' virtual memory >with the file system process. I'm told that the Multics operating system >mapped a file into the virtual address space when it was opened. >Would this be of any advantages (smaller code size, simpler semantics?) >in a Minix-based system? This is also done in Apollo Computer's Domain System and is supported under it's 3 operating systems BSD4.2/SYS V/AEGIS. I have used this mechanism to provide some interesting operations on bitmapped files. The process need only look at a file as an extension of it's address space. It is then possible to do a remapping (ala UNION) between the file and a data structure (ARRAY or STRUCT) and deal with the file as data rather than as external storage. If one combines this capability with a dynamic linking at load, it is possible to map libraries into global shared memory (which get paged in VM) and have very small executables greatly reducing link and load times in the development cycle. It also makes it possible for executables to take advantage of updated libraries without recompilation. The main problem for implementing this with current MINIX is that there is (as you know) no support for Virtual Memory in MINIX. -- John D. Hays, Consultant UUCP: ...!decvax!wanginst!apollo!hays Corporate Systems Engineering ...!uw-beaver!apollo!hays Apollo Computer Inc. CIS: 72725,424 {weekly} !MY OPINIONS, NOT Apollo's!
rde@ukc.UUCP (03/02/87)
Having used and maintained a system with a Multics-like virtual memory
style filing system for the last 6 years...
You can't really do this on a PC because you need a large virtual machine.
Think about it...you need enough address space to hold all the files you
have open.
You could possibly do it on an AT where a big virtual machine can be implemented
using the memory management hardware. It is easy on a 386. But on a PC..no
page faulting and a 20 bit address...no way!
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589henry@utzoo.UUCP (Henry Spencer) (03/03/87)
> I was wondering how difficult it might be to 'integrate' virtual memory > with the file system process. I'm told that the Multics operating system > mapped a file into the virtual address space when it was opened. Multics did indeed do that. The problem is that the ability to do tricks like that is *very* dependent on good memory-management hardware. That's why Unix doesn't do it. An 8088- or 8086-based machine has no hope of doing it. Nor does a bare 68000 as in the ST. The somewhat better MMU in the 80286 just might make it possible in a sleazy and inefficient way on an AT. You really need paging to do it right, and it better be a well- designed paging box at that. > Would this be of any advantages (smaller code size, simpler semantics?) > in a Minix-based system? If anything it complicates the code and the semantics. For one thing, it's not clear how you can do such mapping for non-ordinary files -- directories, devices, and so forth. For another thing, even with a cooperative MMU it becomes very difficult to maintain a file size down to the byte when the MMU only works down to the page. In short, it's an interesting concept but a whole new can of worms. If you are looking for a neat experiment, go ahead. If you are looking for a simple way to improve Minix without introducing serious incompatibilities, forget it. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/05/87)
In article <7730@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> I was wondering how difficult it might be to 'integrate' virtual memory >> with the file system process. I'm told that the Multics operating system >> mapped a file into the virtual address space when it was opened. VMS also allows this, called mapped sections. I used it to improve the performance of our mail system. > >Multics did indeed do that. The problem is that the ability to do tricks >like that is *very* dependent on good memory-management hardware. That's >why Unix doesn't do it. ^^^^^^^^^^^^^^^^^^ I believe that mapped files were in the BSD plans but never implemented. I know I saw it in some initial documentation of BSD< perhaps someone will check and post. > An 8088- or 8086-based machine has no hope of >doing it. Nor does a bare 68000 as in the ST. The somewhat better MMU >in the 80286 just might make it possible in a sleazy and inefficient way >on an AT. You really need paging to do it right, and it better be a well- >designed paging box at that. The 80286 generates a memory fault when accessing a page not mapped, which could also mean 'not in physical memory'. It could set pages write protect, and when a WP fault occurs, change the permissions on the page and set a dirty bit. >"We must choose: the stars or Henry Spencer @ U of Toronto Zoology -- bill davidsen sixhub \ ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen chinet / ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)