🚀 go-pugleaf

In article <1992Sep25.195557.1970@e2big.mko.dec.com>,
marra@tmfeng.enet.dec.com (Dave Marra) writes:
|>From: marra@tmfeng.enet.dec.com (Dave Marra)
|>Newsgroups: comp.sys.dec
|>Subject: Re: Q: VS4000VLC
|>Date: 25 Sep 92 19:55:57 GMT
|>Reply-To: marra@tmfeng.enet.dec.com (Dave Marra)
|>
|>
|>>I thought that as of 5.2, or something, VMS did 'true' highwater
|>marking with
|>>very little overhead. An upgrade of VMS somewhere along the line
|>turned back
|>>on the highwater marking that I had specifically turned off. What
|>kind of
|>>overhead does the new highwater marking entail?

True high water marking is done for sequential files. That is, an
application cannot access any old data beyond the last block of the file
actually written. It gets a block of azeroes if this is attempted. Thus
high water marking is not much of an overhead for sequential files. The old
technique of zeroing out newly allocated blocks of a file is used for other
file organisations.

|>
|>I believe, and I could be wrong, that with highwater marking, when
|>the
|>operating 
|>system is asked for a page of disk memory, it clears the memory prior
|>to giving
|>it to the asker, with the highwater off, it isn't cleared. 
|>Therefore,
|>if you
|>are going to be paging only to a disk, and aren't too worried about
|>security,
|>turning this off should result in less overhead (the clearing of the
|>memory).

Sorry, but I think you are wrong here. High water marking has no effect
on paging If a program page faults for a new page (i.e., one that has not
been used before) then a page of zeroes is always presented to the program.
These are known as demand zero pages.

This is getting to be more of a VMSNET.INTERNALS discussion, so I'll
stop right here.

Tony Arnold,
Manchester Computing Centre,
University of Manchester.