Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!LBL.GOV!nagy%warner.hepnet
From: nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru)
Newsgroups: comp.os.vms
Subject: Re: MPW_HILIMIT --- and page caching
Message-ID: <880708120821.27603e9e@LBL.Gov>
Date: 8 Jul 88 19:08:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 23

> According to what I've been told at one VAX/VMS performance seminar, it
> does not make sense to define a large MPW_HILIMIT. The reason is that whenever
> a process with pages in the modified list terminates, the whole list is
> written to disk, so its size gets down to zero. That's probably why it can
> never grow really big.
     
This is 95+% wrong!  When an image exits, most of its modified pages are
flushed to the free list since they have NOWHERE to go on the disk.  The
only modified pages written back to disk are those from files mapped as
writable sections.  In .EXE files, the code is read-only (99%) and so
become RO pages which are flushed to the free list on termination.
Initialized variables are usually in Copy-On-Reference sections and
unitialized variables (and ones inited to 0) in Demand-Zero sections;
in both these cases the page in memory DOES NOT get written back to the
.EXE file but has the system paging files as their backing store.  When
the image exits it makes no sense (and so VMS does not do it) to write
these pages to the paging file.

= Frank J. Nagy   "VAX Guru & Wizard"
= Fermilab Research Division EED/Controls
= HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY)
= BitNet: NAGY@FNAL
= USnail: Fermilab POB 500 MS/220 Batavia, IL 60510