Path: utzoo!attcan!uunet!lll-winken!xanth!ukma!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request Message-ID: <8905181730.AA08602@postgres.Berkeley.EDU> Date: 18 May 89 17:30:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 67 :> 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. Boy, not only did you miss the point, it flew right past you! If you had read my posting more carefully, you would have noted that I said that systems which do not implement VM would ignore the MEMF_VIRTUAL flag. Are we clear now? Do you understand why it must be MEMF_VIRTUAL and not MEMF_PHYSICAL? It's so that the systems that *do* implement virtual memory are upward compatible from the systems that do not. :> (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. Even MORE flexible if it's a file, eh? :> (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, I leave interpretation up to individual readers but would like to note that your own presumably bad experiences may be getting the best of you here. :> 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 Amusing. This question has already been answered. The problem is to find the data sector right? We are talking 2 hash lookups in the fully cached cased (which will be most of the time). 2 hash table lookups on the sector cache are zilch compared to actual transfer time. :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. Uh, you seem to be under the misconception that seeking in a file takes lots of time when in fact it takes nearly zero time for the fully cached case (2 or 3 control sectors cached). :Valentin -Matt