Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061 From: 451061@UOTTAWA.BITNET (Valentin Pepelea) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request Message-ID: <8905170500.AA25917@jade.berkeley.edu> Date: 17 May 89 03:14:44 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 91 Matt Dillon writes in Message-ID: <8905162209.AA20997@postgres.Berkeley.EDU> > You are clearly missing the point. Certainly I would much rather > have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break > too many programs... more than too many, a *huge* number of programs. Would you not rather break many programs today, when there are so few potential A2500 owners and users of virtual memory, than three years from now when every body will be having MMUs in their Amigas? (wishful thinking) I would rather burn naughty devellopers now, when there is 1 user of VM, than three years from now, when there will be 2 million. > (1) Using a fixed partition restricts the USER's ability to configure the > system the way he likes... Agree with you there, although the driver for the SWAP: device does not necessarely have to be a harddisk.device. Flexibility is maintained, though not as elastic as if a file were used. > (2) It requires an entirely new module to be written to handle the > independent trackdisk.device interface. Definitely not. The SWAP: device should be a mere hard disk partition controlled by access through the harddisk.device. Ultimately a custom driver should be used only if the harddisk.device driver proves to be to slow. Unlikely > (3) It is not implementable in the near future. Preposterous! Virtual memory can be written within a week by somebody who knows what he is doing. A handler will be available by the end of the summer, I will bet my iron ring on that. > (4) it does not ease the way for eventual file mapping which is where UNIX is > going these days. Hmmm, you seem to have Unix etched in your head. I bet you are one of those guys who has written a CSH-like shell for the Amiga. Unix is a prime example of the direction the Amiga should not be going into. Unix is slow, Unix is big, Unix is cumbersome. The Amiga on the other hand is a real-time system, small, compact, fast. Useful. The Amiga provides a common addressing space for all concurrent tasks, a most useful feature than can only be provided in single- user systems. Unix intents to map the individual addressing spaces of each process to a file, which is ideal for multi-user systems where programs have to have their own addressing space. That is clearly not what we are dealing with on the Amiga. We have a single addressing space, and we know in advance the range to which we want this addressing space to be limited to. > (5) Your basic assumption that managing a custom swap > partition would be faster than using a file is incorrect. > The only point I need to embellish upon as the last one. Frankly, > I think that with appropriate modifications to the fast file system, using > the FFS would be nearly as efficient as a custom partition. NOT ONLY THAT > BUT USING IT WITHOUT MODIFICATION WOULD BE VIABLE, and not much slower than > a custom partition. Certainly not more than 10% slower and I'd wager the > difference would be even less than that. ...after my example... > You are assuming here that an FFS file is 3 TIMES SLOWER! Bullshit. Quite clearly, you do not understand. FFS is fast because after an initial sector is found, the following ones are loaded sequentially off the same track. Thus for large files, the tranfer rate is impressive. But for small scattered files, FFS is not better than the old file system. For paging, we have to transfer individual 512 bytes pages which are never needed in a sequential order. Thus the overhead that the filing system introduces to find the approriate sector on disk increases seek time by an order of magnitude. The example I gave said the filing system would be 10 times slower, not 3, thus requiring three times more physical memory. sqrt(10)=3 For swapping page 316, it is much simpler to transfer directly sector 316 through the trackdisk.device, than having to determine the location of the sector through a filing system. The only way a filing system could be used in this case would be by an indexed access method, or database access method filing system. A good example of such a marvel is INFOS II on Data General computers. I hear the Software Distillery is working on just such a beast. No wonder, since John Toebes used to hack on DG systems. Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA