Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!umd5!umbc3!dave
From: dave@umbc3.UMD.EDU (David A Freeman)
Newsgroups: comp.os.vms
Subject: Re: MPW_HILIMIT --- and page caching
Message-ID: <1091@umbc3.UMD.EDU>
Date: 19 Jul 88 00:50:17 GMT
References: <880708120821.27603e9e@LBL.Gov> <548@csdgwy.csd.unsw.oz>
Reply-To: dave@umbc3.UMD.EDU (David A Freeman)
Organization: University of Maryland, Baltimore County
Lines: 41

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