Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!dogie.macc.wisc.edu!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: 19 May 89 09:17:17 GMT References: <8905181705.AA08260@postgres.Berkeley.EDU> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 72 In-reply-to: dillon@POSTGRES.BERKELEY.EDU's message of 18 May 89 17:05:35 GMT In article <8905181705.AA08260@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: Hey Hey! A guy can make mistakes! You are right of course... all (or most) of real memory should be under VM but have the ability to 'lock' pages into memory as has been mentioned. Well, at least you'll admit to them... :-) The only problem is that AllocMem() requests are normally quite small... much smaller than a page, so management becomes more difficult if all of real memory is in VM. Still, it isn't much of a problem. Sure, they're small, but that needn't pose a problem. Simply force the pager to free pages (as necessary) enough to satisfy the request. if there's no memory left, and 8 bytes are allocated, then it should free a (presumably) 512 byte page from VM and allocate 8 bytes leaving the other 504 still free. [this is ignoring system overhead, clearly.] Of course, it should try to free pages which would merge with the already-free memory for efficiency. [I consider memory efficiency to be more important than speed efficiency, for the most part.] On this MEMF_PHYSICAL vs MEMF_VIRTUAL bit. Sure MEMF_PHYSICAL is a nice way to say 'I want memory and it should be locked', and I'd much rather have that than MEMF_VIRTUAL (which says 'I want this memory to be pagable'), but really the only way to guarentee upward compatibility is to make physical the default and MEMF_VIRTUAL the exception. Thus have a MEMF_VIRTUAL AllocMem() flag and not a MEMF_PHYSICAL flag. It helps guarantee compatibility, but would tend to discourage its use. If people have to go out of their way to lock the memory allocated into real memory, then they're not normally likely to do it unless there's a need to. Similarly, people aren't likely to add an MEMF_VIRTUAL flag unless there's particular reason for it. Particularly susceptible would be small programs and most anything written by someone who has no MMU and does not expect to get one. Keep in mind that many, many programmers are lazy. Most, to be sure. It's hard enough to get them to stay within system guidelines well enough not to crash the entire machine. Consider the issue of screen sizes... people who use morerows (such as myself) will often get tired of resizing new windows that applications create (such as, say, DME... :-) to the real screen size instead of the program's assumed screen size. The programmer could include code to check the actual size of the screen, yet usually does not. Particularly if the programmer doesn't use anything but a 640x200 screen. They often don't support well any screen size approaching the possible 704x440 or so you can get. With that aside aside, you can expect that many programmers will ignore a MEMF_VIRTUAL flag, leaving people WITH an MMU in trouble. I suggest that a preferable solution would be to add a MEMF_LOCKED (and/or MEMF_PHYSICAL) flag, and make VM the default unless explicitly requested locked memory is allocated. For compatibility, perhaps the best solution would be the ability to mark a particular task as being locked in memory, so everything it allocates (as well as the code and data) will automatically have the MEMF_LOCKED flag set. And, of course, there would need to be an easy way to run an old program locked in memory. [a utility program, probably, or maybe a modification of the loader format?] This way, you could get unchanged operation (at slightly more effort) on those few programs where it's likely to *really* matter, (probably would need some trial and error) and other programs could take advantage of virtual memory without having to be recompiled or modified. 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.