[comp.os.vms] MPW_HILIMIT --- and page caching

nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) (07/09/88)

> 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

ewa@csdgwy.csd.unsw.oz (07/15/88)

In article <880708120821.27603e9e@LBL.Gov>, nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) writes:
>> 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

I was not referring to IMAGE exit, but to PROCESS termination, therefore
the above argument is irrelevant. Also I used the term DISK in general sense,
meaning page file, swap file or private file; all on disk, aren't they ...

Anyway, true or not (I would be reluctant to put a percentage on it),
it would be interesting to find another explanation for the modified page 
list on a busy system to go down to zero.

   +----------------------------------------------------------------------+
   |  E.Z. Bem,			       ASCnet: ewa@csdgwy.csd.unsw.oz     |
   |  VAX/VMS Systems Group,          Infopsi: ewa@csdgwy.unsw.edu.au     |
   |  University of New South Wales,      FAX: 61 2 662 8665              |
   |  PO Box 1, Kensington, 2033 NSW,	Phone: 61 2 697 2920              |
   |  AUSTRALIA                                                           |
   |                                                                      |
   |            Daily a clever man learns something, daily a wise         |
   |                  man gives up a certainty, perhaps...                |
   +----------------------------------------------------------------------+

dave@umbc3.UMD.EDU (David A Freeman) (07/19/88)

In article <548@csdgwy.csd.unsw.oz> ewa@csdgwy.csd.unsw.oz writes:
>In article <880708120821.27603e9e@LBL.Gov>, nagy%warner.hepnet@LBL.GOV (Frank J. Nagy, VAX Wizard & Guru) writes:
>>> 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
>
>I was not referring to IMAGE exit, but to PROCESS termination, therefore
>the above argument is irrelevant. Also I used the term DISK in general sense,
>meaning page file, swap file or private file; all on disk, aren't they ...

With "monitor page" you can see which page faults are hard (on disk) and
which are in memory. (free list, modified list, and also global valid)
Hard faults are much more costly than soft faults (memory) as hard faults
have to locate the page and setup a direct I/O.

>Anyway, true or not (I would be reluctant to put a percentage on it),
>it would be interesting to find another explanation for the modified page 
>list on a busy system to go down to zero.

Simple. The modified page cach is only for: MODIFIED pages that are replaced
from a processes working set.  First, most page faults are on non-modified 
pages.  Second, if the process accesses these pages they are added back to 
the processes working set.  To verify do a monitor page and watch the page 
write rate.  You can see that process termination does not cause a modified 
page write.  


				
					dave





dave@umbc3.umd.edu	
dave@umbc	bitnet