jds@mimsy.UUCP (James da Silva) (04/30/89)
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? > > Personally, I wouldn't want to run more processes in Minix. ... [because it gets SLOW] 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 be fixed, by the way. 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. To Steve Ackerman: I'm sure I speak for many others when I say please please oh please post your swapper! Even if you run out of free time and can't finish it or you win the Pennsylvania lottery and move to Rio, post what you have! Nations will sing your praise! Ahem, ok. I've regained my composure. Minix needs a swapper. Jaime ........................................................................... : domain: jds@mimsy.umd.edu James da Silva : path: uunet!mimsy!jds
bds@lzaz.ATT.COM (B.SZABLAK) (05/01/89)
Someone asked if anyone had thought about adding swapping on the ST version of Minix. Well, I had thought about it for 2 minutes and decided it wasn't worth any more effort. The ST process image contains absolute address references which would require that the process be swapped in at the exact same position in memory that it was swapped out of. This could be quite difficult to arrange if the memory freed by swapping was fragmented as new processes were created and destroyed. It really doesn't seem to be worth the effort. Naturally the PC version doesn't have this problem, and with typical PC configurations having at most 640K available it might be worth while.
ackerman@kira.uvm.edu (Steve Ackerman) (05/02/89)
I've gotten some inquiries about the state of our swapper, so I thought I would explain where we are in the developement, and what problems we have encountered. Hopefully, someone has already dealt with this problem, or may be able to give a good suggestion. Right now, our swapper works fine (as far as swapping processes in and out goes*); however, we have problems with the fact that Minix expects the process to be in memory when I/O or messages come in. For example, we swap out a process that is blocked on a send/receive system call first. If there is none, we will swap a process out that is at the tail of the ready queue. That's fine as far as that goes, and we don't have any problems swapping out running processes.* Obviously, when the process is swapped out, it doesn't own any memory. This is were the problems start. When something like the FS does a send/reply to a process, the kernel assumes the process is in memory, and copies the message to the swapped out process' data segment. However, the process does not really own that memory - it is most likely being used by another process, thereby clobbering its text/data. We fixed this problem by providing a simple message buffering scheme for processes swapped out. However, the problem goes a little deeper. Take, for example, the TTY driver. If the shell/editor (such as elle) is blocked on a read(), and the memory demands invoke the swapper, elle, will be chosen for swap out. If, during the time that elle is swapped out, a user hits a key, the TTY driver will attempt to copy the typed character directly to the user address space; therefore, encountering the same problem as before. Again, a work around scheme has been developed (a kludge if you will). There are more instances of this type of occurance. For example, I believe the Printer driver will read directly from the process' data space. Other problems include a few race conditions that need to be hammered out. Also, I'm not sure what will happen when a process is blocked on a pipe, but I suspect the same type of problem as the TTY driver. This brings me to my question - Does anyone have a better solution than to go through the code, find all the places where this type of problem occurs, and provide a work around? I think that if the swapper was operating in a protected mode environment, a write/read from a swapped out segment would generate an exception that could be caught, but I'm not sure (don't have my 286/386 book with me, so I can't look it up!). But the problem still remains in Real Mode. I think the problem would exist on the Atari version as well. Anyone have a suggestion? I've heard from Stan Kobylanski, who's also working on a swapper. Is there anyone else out there who is? It would be nice if we could discuss these problems and solutions to them. Thanks! Steve *I should qualify these statements: these parts of the swapper APPEAR to work (we haven't noticed any FATAL bugs). However, in a dynamic system, the swapper is still buggy, and needs work.
Leisner.Henr@xerox.com (marty) (05/03/89)
I think one of the reason PC-Minix bogs down is the buffer cache is only 40K. This is a guess -- not a hard fact. An attempt was made to alleviate the problem with a ram disk, but that's not the Unix way of doing things -- a larger buffer cache would be nice (i.e one which can hold all the passes of the C compiler, the libraries and the editor and shell -- about 200k would be nice). Then you get into these nasty 8086 segmentation problems. I don't think swapping is the answer -- I tend to agree with ast (make the OS big enough and swapping becomes a self fulfilling prophecy). A system that can use more RAM for processes and buffer cache would be nice. (I thought CS professors like to assign tasks like "write a swapper" to go with things like "write a drum driver"). marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: martin leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
ugkamins@sunybcs.uucp (John Kaminski) (05/03/89)
In article <1164@uvm-gen.UUCP> ackerman@kira.uvm.edu (Steve Ackerman) writes:
=>and the memory demands invoke the swapper, elle, will be chosen for
=>swap out. If, during the time that elle is swapped out, a user hits a
=>key, the TTY driver will attempt to copy the typed character directly
=>to the user address space; therefore, encountering the same problem as
=>before. Again, a work around scheme has been developed (a kludge if
=>you will).
=>
=>There are more instances of this type of occurance. For example, I
=>believe the Printer driver will read directly from the process' data
=>space. Other problems include a few race conditions that need to be
=>hammered out. Also, I'm not sure what will happen when a process is
=>blocked on a pipe, but I suspect the same type of problem as the TTY
=>driver.
=>
=>This brings me to my question - Does anyone have a better solution
=>than to go through the code, find all the places where this type of
=>problem occurs, and provide a work around? I think that if the
=>swapper was operating in a protected mode environment, a write/read
=>from a swapped out segment would generate an exception that could be
=>caught, but I'm not sure (don't have my 286/386 book with me, so I
=>can't look it up!). But the problem still remains in Real Mode. I
=>think the problem would exist on the Atari version as well. Anyone
=>have a suggestion?
how 'bout tweaking the code for phys_copy, send_rec, etc. instead of worrying
about individual instances? Does any of the MINIX code *NOT* use these sys-
tem routines? I think it highly unlikely that it would. I would think that
swap information is a new part of the process table, and therefore you could
access the swap info when doing a send_rec() for instance.
Hey, I know this might sound obvious, but sometimes the obvious can seem
soooooooooo concealed until a fresh set of eyes looks at the problem.aj-mberg@dasys1.UUCP (Micha Berger) (05/14/89)
I have a similar question, but somewhat more naive. Why is there no system call that fork and exec's? Why must I copy data, which more often than not will be wasted? mb -- Micha Berger -------------------------------------v------------------------------------------"The world stands on three things: on| AishDas Society / Aspaklaria Publicationsthe Torah, on Service [to the L-rd], | 73-32 173 St, Hillcrest, NY 11366 and on Acts of Kindness" | (718) 380 - 7572 - Shimon the Righteous, Avos 1:2 | email: ...cmcl1!dasys!aj-mberg -------------------------------------^------------------------------------------