🚀 go-pugleaf

Being a Lisp programmer, I have also observed that Unix (and many other
O.S.'s also) tends to lose when running large programs that don't fit a
"typical" VM behavior pattern.

One problem is that many O.S.'s use a purely global page replacement
algorithm: no consideration is given to what process that page belongs to,
and to what the history of that process is.  

Many classic VM algorithms (such as Working Set) do consider processes and
degree of thrashing, etc., but these algorithms seem to be little used in
recently designed o.s.'es.  [Since this is comp.arch, I will note in passing
that is may be partly due to brain-dead VM hardware, such as the VAX, which
doesn't even have a reference bit.]  This is probably because people
discovered that with lower degrees of time-sharing and larger memories,
global strategies worked just as well for the "typical" workload.

As to how an O.S. could address these problems, I strongly agree that a
dynamic strategy is preferable to a batch-oriented one.  A Lisp process
generally persists for an entire interactive session, and may exhibit a wide
range of different behaviors during that period.  The O.S. must not only
recognise when the process is antisocial, it must also recognize when it
becomes social again.

As to exactly what to do when you discover that memory is over-committed:
>    Whether "on hold" means explicitly swapped out, or suspended, or
>    simply restricted to a small, but non-zero number of physical memory
>    pages is an implementation issue (about which I was hoping to hear
>    some interesting discussion).

It's hard to know exactly what you mean by "explicitly swapped out" in a
paged VM system.  Unlike in a true swapping system, you are never going to
write out clean pages.  The question is only what you are going to do to the
processe's resident pages at the time you decide to "swap" it.  You can:
 -- Clean all the dirty pages (perhaps freeing them once cleaned), and
 -- free all of the clean pages.

Scheduling writes of all the clean pages is probably worthwhile; it probably
doesn't make any difference whether you free the clean pages or just allow
them to be replaced when you page the other process in.

"suspending" the process presumably means stopping the process, but doing
neither of the above actions on its pages.  This would work pretty well,
especially if the VM system cleans dirty pages efficiently (many at a time).

Restricting a thrashing process to even less memory is a bad idea.  Although
it will allow other processes to get them memory they need, the restricted
process will thrash even more, soaking up disk bandwidth and O.S. runtime
that could be used by other processes.  There's no point in trying to let
the thrashing process run, since it's not going to be able to get anything
done without the memory it needs.

  Rob