Is 4MB Enough for Interactive?

[Piercarlo Grandi]

On 1 Feb 91 11:35:57 GMT, tkevans at fallst.UUCP (Tim Evans) said:

tkevans> Interactive claims their UNIX requires a minimum of 4MB RAM.  I've
tkevans> been down this road before, with Microport's System V/AT ('286)
tkevans> claiming to run in 512K.  In that case, I started out at 1MB and
tkevans> found the system swapping when going from input to command mode
tkevans> in 'vi'!

That particular bogosity is the result of a double bogosity;

The first problem is that the SVR2 'vi' has a bug that would make it
allocate a new input buffer every time input mode is entered.
Recompiling 'vi' from BSD sources, or using elvis or jove, possibly with
a better malloc (mine, for example) cured this problem. If you want to
be sure of what I say, just invoke vi, switch to another screen, and do
a ps -al; then switch to vi, enter input mode, type one character, exit
input mode and switch back to do another ps -al; repeat.  You will note
that every time you switch into input mode the size of the process grows
by 1KB, even if you only typed one character.

The other problem iss that, just like SVR3.2, SVR2 does expansion swaps,
that is when a program requires memory and there is no free memory it is
the one that gets swapped out to make free some memory, not the least
active one. SVR2 is particularly bad because it does expansion swap also
when there is no free memory near the expanding process, not just no
free memory in the system like SVR3.2. This because processes have their
data segments held contiguous instead of scattered around.

The end result is that 'vi' under SVR2, that is Microport SV/AT, is
typically swapped on every switch to input mode unless there is about
ten times as much memory as that actually needed.

SVR3.2 still has expansion swaps, which means that you still have to
have memory in excess of ten times of that used by the working sets of
active processes, because in order to get decent performance swaps
expension swaps simply must never be triggered, and since an expansion
swap is triggered every time a process grows and there is little "free"
memory (which is always true under any sensibly configured system), you
must guarantee that there is always free memory by having more real
memory than the combined size of all active processes (which is not
sensible at all).

tkevans> Needless to say, doubling uPort's minimum requirement wasn't
tkevans> enough.  I'm now running with 4MB and things are finally
tkevans> comfortable.

I used to run fairly well in 1MB with Microport 2.4, using my own malloc
and jove or elvis as editors. Using the SVR2 'vi' is a loss in any case,
as it has many crippling bugs other than the one by which it grows on
every switch to input mode. If you like 'vi', switch to elvis which is
arguably better, and surely smaller and faster, than the original; if
you like 'emacs', switch to jove. You will find that things improve
immeasurably, and the 4MB you already have will look like a lot. Take
advantage of this by upping the buffer cache to 1MB or even more, and
your old 286 will suddendly look very fast indeed, as your edits and
compiles no longer cause disk IO. Other tuning advice: set the sticky
bit on frequently *loaded* executables, especially those of a certain
size, like vi, jove, as, cc, ccom, ld, optim, ls, (maybe also sh/csh).
If you have two disks, configure your swap area on the non root disk.

tkevans> Sooo, now that I'm going to a '386, I don't want to have to go
tkevans> down the road of having to upgrade the system after I buy it.
tkevans> How well with Interactive perform on a single-usre "personal"
tkevans> machine in 4MB?

Not terribly well. Also, if you don't have special reasons to go for
Interactive, and you really need SVR3.2, consider Esix, which costs
significantly less.

If you really want a system that will be economical of memory, choose
one with with better swapping policies, use Xenix/386. It is a fairly
funny version of Unix (and you had better use GCC instead of its native
Microsoft C compiler), but it will not thrash doing expansions swaps.
It's lean and fast. Support everything. It's also fairly expensive.

If you want something different, try SVR4. Dell's is best, IMNHO, but
you *must* have 8MB and an Archive 150MB SCSI tape with an Adaptec SCSI
controller to install it. If you have the money, seriously consider
buying a Dell 386(DX or SX) with their SVR4 on it.

Otherwise there are Microport and UHC, both of which offer fairly sweet
upgrade deals to those who turn in the floppies of their previous Unix,
286 or 386. SVR4 seems to have better paging and swapping policies, and
it is know to run decently in 4MB, *if suitably trimmed*. Please always
reconfigure after installation.


Please note that swapping and paging are the *normal* mode of operation
of a multitasking OS; as a rule, only 1 task in 10 is active at any one
time, and therefore needs to be resident (as a rule only 1 page in 4 of
a task is being actively referenced). This means that if the time to
swap in a task is small compared with the time a task sleeps between
activations, swapping is a win.

Usually the working set of an interactive application is from a dozen to
a couple hundred KB, so to swap it in on a machine that can transfer
500-1000KB/sec. takes a small and imperceptible fraction of a second.

With interactive programs that do not put the terminal in raw mode, for
example any line oriented command like the shell (if command line
editing is done in a line discipline or is done cleverly without raw
mode), the time between activations is the time required to type a line;
this usually is well over a second, so that while you type the line the
process can be swapped out, and when you type return, it can be swapped
in, with an almost invisible delay.

Since the interval between keystrokes is usually of the same order of
magnitude as the swap-out/in time, programs that do raw mode input like
full screeen editors need to be continuously resident. That is one (the
major) reason why a PDP-11/70 that could support N terminals using ed
would only support N/3 (another rule of thumb) using vi. Naturally it
would not be that difficult to solve the problem of raw mode input
programs in a more intelligent way. In a sense a solution has been
provided by the onset of paging, which has meant that while you type in
a line to a raw mode program only the *two* pages containing the code
for the typein routine and the file buffer really need to be resident.

Ahem: unfortunately the above is true only if the swapper policy and the
swapper implementation (and the pager, the shell, and the full screen
editor) are decently done by people who actually understand computers
and operating systems, which unfortunately is virtually never true, for
latter day Unixes.



--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk