Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: Virtual Memory / doable 1.4 request Message-ID: Date: 17 May 89 06:31:46 GMT References: <8905132040.AA27524@postgres.Berkeley.EDU> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 114 In-reply-to: dillon@POSTGRES.BERKELEY.EDU's message of 13 May 89 20:40:42 GMT In article <8905132040.AA27524@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Refering back to my first article, I have a couple more >implementation ideas: Your first article was great... just the way to get VM going on the Amiga. > (1) Since a distinction between real and virtual memory exists, the > user should be able to set how much real memory the virtual memory > will be mapped to. For example, if we have 2MB of ram and a > process that is using 20MB of virtual memory, we do not want to > use all 2MB for VM simply because many programs will still need > to allocate non-virtual memory. Matt, Matt... Here you seem to suffer from a lack of foresight. This is NOT an ideal way to implement it. I'd say the proper way to implement it is to modify AllocMem and design the pager such that all available memory (i.e. unallocated real RAM) may be used for VM. If you have 2MB of RAM and a process is using 20MB of VM, and another process is using .5MB (including system overhead, we'll say) of real RAM, then the remaining 1.5MB of RAM should be used for the VM. Then, if the other process were to allocate another 1MB of real RAM, then AllocMem should call the pager to flush 1MB of the VM pages allocated, and reallocate them as real RAM for the other process. Similarly, upon a FreeMem, the system should return as much of the freed memory as is usable [that are of full VM pagesize, after freelist merge] to the pager to lessen paging required. In this way, if there is real RAM free, any program which needs it can allocate it, but if it is unused, then let it be used for VM as necessary, reclaiming the VM-paging real RAM pages on demand. You get dynamic usage of the available memory, and optimum efficiency at all times, without worrying how much memory you need to set aside for either real RAM or VM paging space. What's leftover is simply used for paging, automatically. Remember, think *dynamic*. Catch-word of the day. :-) > The beauty of it all is that no matter how little or how much you > specify, no program using VM will know the difference. The more > you reserve, the less paging will have to go on. But this dynamic method is even more beautiful, because you don't waste memory on either unallocated (but reserved) real RAM nor on unused (but reserved) VM paging memory. Again, the program using VM won't know the difference, except that speed will be affected. Instead of less paging when you reserve more RAM, you get less paging when you're USING less RAM. And when you use more, it will page more accordingly, yet not tell you the system is out of RAM. [Clearly, at least ONE page must remain to page to, but the rest can be reclaimed at need.] > (2) The Maximum amount of virtual memory in the system can be > implemented in two ways. I would like to say something like this > in s:startup-sequence : > enablevm 30% hdv:virtual-memory 20M Perhaps have VM automatically use some default file if a program attempts to use VM when no file has been thus set? Or, maybe have MEMF_VIRTUAL memory allocated in real RAM until an enablevm, at which time, all previously allocated MEMF_VIRTUAL pages would be remapped (or reallocated, if need be) into virtual memory pages... That would perhaps be the best way to go. There should be a disablevm program, also, which would remap/reallocate vitual pages into real RAM (if possible) and disable the pager until an enablevm. [...] > (A) Open(file,1006) and write 20MB of zero's (or garbage), [...] > (B) Open(file,1006) and write nothing yet. [...] > (C) Reserve a partition to be used for VM. [...] I propose enablevm use the following template: enablevm file/a size/a where "file" is either a file, volume or partition to page to, using "VM:" if file is unspecified, or "HD0:VM" [maybe] if no VM: exists. If no VM: exists, ASSIGN it to the file or partition actually used, whether specified on the command line or taken as the default default. ["HD0:VM" or whatever] The "size" argument would only be applicable if paging to a file and not a partition, device or volume. If paging to a file, "size" would specify how large the paging file must start. If no size is given, the paging file starts empty. In either case, the file would be expanded as necessary, assuming space is available for expansion. If VM is already enabled upon an enablevm, the new enablevm would change the paging file (device, partition, volume) to the specified (or default) one, copying over all the pages from the old paging file, and probably (but not necessarily) deleting the old paging file. Disablevm would need no arguments and would simply force all VM pages back into real RAM if possible and disable the pager. Well, perhaps a switch or two to define the action taken if not enough real RAM exists for the virtual pages. [leave remapped pages in real RAM and leave the pager going/remap all pages back to the VM file/partition and leave the pager enabled/dump unmapped pages, delete paging file and disable pager/etc.] This way, you could get the best of all worlds. True, it would be slightly more programming effort for C-A than a simpler method, but not that much, and I think it is the right way to do it. Comments? :-) Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.