From: hdavids@mswe.dnet.ms.philips.nl (Henk Davids)
Newsgroups: comp.os.vms
Subject: Image activations, page faults and disk I/O
Date: 26 Jan 93 15:52:08 +0100
Organization: Philips Medical Systems Nederland

The following behaviour of VMS has never ceased to amaze me. I would
be very happy if someone with a little insight into the philosophy
that's behind the design of VMS could shed some light on this.
I read somewhere that this subject has been treated (beaten to death?)
on vmsnet.internals some time ago, so I apologize in advance if this
is a waste of bandwidth *).  We are running VMS 5.5-1. 

Image activations under VMS are expensive. What's worse is that the
repeated activation of the same image by the same process does not get
cheaper on successive calls. Likewise, multiple activations of a
particular image by many processes are probably just as expensive.

Now if you're in a software development shop (like me), many users
execute a lot of relatively simple DCL commands, or short DCL
procedures, in rapid succession. Unfortunately, many DCL commands lead
to the activation of separate images (I can only guess that this setup
was considered the best way when systems were usually short on
memory). The net result of this is, that it's easy to bring VMS to
its knees just by running a simple procedure, for instance one that
results in repeated activations of a few DCL images. Try a loop of for
instance "set process/name=xxx" and compare that to a loop with a
built-in command, like "set default []".

A lot of the performance degradation is caused by the page-faults that
the image startup incurs. And these are hard page faults too! In the
past I used to think that unmodified pages of an image file would get
reused, if not for the next activation of the same image by another
process, then at least for multiple activations by the same process.
Well, some of them are...

The image activator uses some optimizations for so-called Known Files.
These are images that have been made known to the system by the
INSTALL utility.  This saves a file lookup, and possibly the reading
of the image-header if the image was installed header-resident. But
the actual code pages of the image still have to be read from disk.
When you INSTALL an entry in the Known Files list with the /SHARE
qualifier, a global section will be created for every pure code
section in the image file.  By default, all images that are part of
DCL are installed this way.  Presumably, the image activator should
then map process pages to these global sections. However, that does
not explain all the disk accesses that I see. So, the question is:
does the image activator in this release of VMS really use these
global sections?

At image rundown, the pages that contain the image data are moved to
the free list. Normally process pages that are added to the free list
can be reused, if they have not yet been used for something else. I
suspect that image rundown removes the connection between the process
and the image pages, because even on an empty VMS system the hard page
faults keep the disk busy. Why would image rundown go to such trouble?

Yet another question. I cannot see a way to defeat VMS here. Some time
ago, someone posted a little program (turbo) that was designed to keep
pages of designated images in memory. Of course, we tried this, but it
didn't work for us as advertised. Or perhaps the basic VMS mechanism,
using global sections, is already working so well that the effect
cannot be measured on our system? Has anybody who tried turbo seen
improvements in performance?

Another suggestion: failing a general solution, perhaps DEC could
provide a DCL image in which al lot of these images have been combined
into one in future versions of VMS, for those of us that have plenty
of memory, but not that much bandwidth for page faults? I'm thinking
especially of popular images like SET, DIRECTORY, COPY, RENAME, DELETE
etc.

Yet another puzzle: why would image rundown have to deallocate all
your pages in P0 space? Couldn't it just leave the working-set intact,
so that multiple activations of the same image could re-use what was
left over?

Suggestions, solutions (and flames :) are welcome.

						Henk

*) I never thought that I would have to be so careful not to draw
   flames on comp.os.vms...