Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!udel!mmdf From: SJONES%HAMPVMS.BITNET@cunyvm.cuny.edu (Steve Jones - Hampshire College) Newsgroups: comp.os.minix Subject: Re: Swapping [in PC Minix] Message-ID: <14993@louie.udel.EDU> Date: 9 May 89 12:20:48 GMT Sender: mmdf@udel.EDU Lines: 89 Summary: Memory management must become more sophisticated as system use Summary: increases and applications become more demanding. #From: James da Silva Date: Sun, 30 Apr 89 16:54:12 GMT #Subject: Swapping (was Re: Blitter with fork) # #In article <2972@sun.soe.clarkson.edu> jk0@sun.soe.clarkson.edu #(Jason Coughlin) writes: #>From article <1162@uvm-gen.UUCP>, by ackerman@kira.uvm.edu (Steve Ackerman): #>> My friend and I have been working on a swapper for Minix 1.3 PC. #> #> My understanding of the situation is that swapping doesn't have #>anything to do with process SIZE on the PC (probably different on the #>ST). It will only allow you to run MORE processes. VM anyone? #> # #It's true that swapping won't allow bigger processes in PC Minix. It's #also true that Minix performs badly with N processes running, N > 2, due #(in my opinion) mostly to the fact that FS is single-tasking. This could . . . #But, swapping to a hard disk would still be a big win. Consider the common #(at least for me) case where you want to run a make in the background and #do some editing and poking around in the foreground. You have to be very #careful now because if you use up too much memory in the foreground, the #make will die a horrible death. Ooops. The same thing happens if you #actually want to hang a terminal on one of your tty ports and log in that #way. Uucp anyone? Cron? Degraded performance in these cases is #infinitely preferable to dying processes. [ Sorry about the mass of context... ] There is another very serious problem that many have probably run into at this point. Due to many performance tradeoffs, the tendancy toward simplicity, and the intended use of Minix (i.e. a living demo, more than a combat-duty OS) the Memory Manager (MM) uses a first-fit algorithm when starting up new processes. This is fine and fast, but it doesn't deal too well when fragmen- tation becomes an issue. For instance if I happen to set a `make' up in the background, I then have to be very careful about what I do next and when. It has frequently happened that make pokes around files to see what it has to do, and I start up Elle. When make starts up cc and then cem and cpp, the MM looks around for large contiguous blocks of memory. Because of what was running where and when, Elle is occupying the middle of over 200k of free space; MM can't find large enough holes for cem or cpp; the make dies with an `out of memory' error, or something like that. This is without cron running, as I'm usually careful to kill it before even thinking about doing a make in the background. Right now cron doesn't do too much and I can get away with that. But if uucp/news were running on this machine... The same thing has happened when a terminal is hung on COM1 and someone logs in on it while a make is in progress. If the shell or some command happens to be in the wrong place at the wrong time due to other things coming and going, well... you get the picture. One solution would be burping memory - periodic compaction of all those fragments into one big hole. This would necessitate moving the various processes around in memory and adjusting their segment registers while they aren't running. This is something that could be done independantly, but it is frequently one of the advantages, if not a goal, of swapping. Swapping not only makes memory somewhat more available by moving hung processes out of main memory, it also allows for their straightforward relocation upon being swapped in. Personally I'm leaning toward having swapping in Minix, but at the same time I realize that my goal is to have a feature-rich (compared to MS-DOS) system that I can modify at will - or at least poke around - and afford to keep in my home. I like the idea of reliability; not having to worry about starting some process in the background and having it terminate because of a fairly inocuous event in the foreground. I'd point out that a very useful addition to any swapping system would be the implementation of process priorities. Add a few more queues for user processes; something on a lower priority queue should be swapped out first. I was going to say a few things about the size and the ease of comprehension of Minix, but I've got an exam this morning... So far as I can see, if the swapper is done in a well thought out manner, if the implementation is simple and straight-forward (as possible), then it would be a good addition. If it could be disabled or enabled on the fly by a message from the MM and an invoking system call, it would be ideal. If for some reason it doesn't fly, or is unavailable on non-protected/native mode machines, a compactor task would be equally valuable. --Steve. BITNET: sjones@hampvms INET: sjones%hampvms.bitnet@mitvma.mit.edu CSNET: sjones%hamp@umass-cs UUCP: ...uunet!hampvms.bitnet!sjones USnail: box 753; Hampshire College; Amherst, MA 01002 "When you have learned to snatch the error code from the trap frame, it will be time for you to leave." -- The Tao of Programming