SJONES%HAMPVMS.BITNET@cunyvm.cuny.edu (Steve Jones - Hampshire College) (05/09/89)
Summary: Memory management must become more sophisticated as system use
Summary: increases and applications become more demanding.
#From: James da Silva <jds@MIMSY.UUCP> 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