Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!uvm-gen!ackerman
From: ackerman@kira.uvm.edu (Steve Ackerman)
Newsgroups: comp.os.minix
Subject: Re: Swapping (was Re: Blitter with fork)
Message-ID: <1164@uvm-gen.UUCP>
Date: 1 May 89 22:15:45 GMT
Sender: nobody@uvm-gen.UUCP
Organization: EMBA-CF, University of Vermont
Lines: 60



  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.