🚀 go-pugleaf

In article <78@alberta.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes:
>People who are saying "the 205 runs programs x, y, and z faster without VM than
>with VM" are looking at only one job at a time. This is fine if your 205 does
>ONLY 1 thing all day, every day. Anyone who was around in the days of
>"batch only" knows this argument inside and out. Batch is fine if you want
>to maximize individual program performance, but overall turnaround time is 
>dreadful, since ALL things sit in the queue, including the 1/2 second
>practice runs.

>Chris Shaw    cdshaw@alberta

A rehash of past arguments, about the working through huge matrix problem:
   "By the time we reach the end of the list, the front of the list will
have been paged out".
    If the front of the matrix has been paged out, that means that the
matrix was too big to fit in physical memory. That means that with no
paging, the performance would be 0 -- a 100% degradation.
  "We can take advantage of disk seek times -- just put the data on
close tracks."
    All the disk systems I have ever seen become somewhat fragmented
over time. 
    Also note that, because of intelligent i/o controllers, pulling a
page off of disk takes virtually no CPU time, since the processor is
running another process while the first one is blocked waiting for the
i/o processor to bring in the page (assuming a multi-tasking system --
Crays and such DO multi-task, no?). In otherwords taking advantage of
explicit multi-processing.

Most of the other arguments seen have been spurious line noise :-)
:-). The only one which is really valid is the table lookup times
necessary for paging. Worst case: the large matrix previously
discussed.  For n=page size, every n bytes we have to fetch a new
associative table entry, upon which one-two levels of a tree must be
traversed. There is also the overhead of paging in the MMU lookup
table the initial time. With today's faster disk drives, larger pages
may help, both in increasing the time N between memory-to-associative
fetches, and in decreasing the size of the MMU lookup table. If 4k was
OK back in Multics days, 8K or even 16K might work today. Also note
that this is WORST CASE. Your mileage will probably be better.

I must conclude that for 4k word pages, every 4k memory operations, a
2-4 cycle overhead would be necessary. or, a 4/4096 reduction in
performance. If we are talking about a 100 MIPS machine, it would now
only be running at 99.92 MIPS. Like wow. Especially considering that
because associative lookups probably run about the same speed as
checking bounds registers, the memory speed would be otherwise about
the same.

Another argument was that paging messes up pipelining.  Correct me if
I'm wrong (we obviously don't have a Cray handy :-), but a Cray only
does pipelined vector operations upon the vector registers (although I
think filling and saving those registers are pipelined operations,
also). Requiring vectors to be page-aligned and having the pages the
same size as the registers or a binary size larger would eliminate any
pipeline lossage (just do your virtual memory grocking BEFORE you get
your pipeline rolling). Since the compilers already have to do
considerable grocking to vectorize code, that doesn't seem too
extreme. And, of course, MIPS machines & others prove that for
ordinary code, pipelining and paging are not mutually exclusive.

Of course, the OTHER Big Win of paging is when you want to run a Truly
Humongous working set of programs.. But I think others have already
covered this, plus there's always the argument "Hey, I've got offset
registers and 2 gigabytes of RAM, what more could I want!". Upon which
someone will discover a problem that takes 2,147,483,650 bytes to
solve...

In summary, I really can't see any reason to not have paging, and
since there's a multitude of reasons to HAVE paging (running problem
sets larger than available memory, "graceful" user response time as
vs. multitasking schemes such as segmentation or swapping, etc.)...
-- 

      Eric Green {akgua,ut-sally}!usl!elg
        (Snail Mail P.O. Box 92191, Lafayette, LA 70509)

" In the beginning the Universe was created. This has made a lot of
 people very angry and been widely regarded as a bad move."