🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2065

Re: Memory utilization & inter-process contention

#2065
From: weaver
Date: Thu, 31 Aug 1989 16:19
33 lines
2400 bytes
In article <2396@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>Simulate reference bits by making the page non-RW, and faulting when you
>>try to read - voila, a reference, and then you just make the page readable.
>
>Yes, that's the trick used by [34].xBSD; I was wondering whether VMS had
>some other scheme that used neither real nor simulated reference bits.

The 'modified FIFO' scheme used by VMS works as follows: each process at any 
given time has a fixed number of pages dedicated to it (the number is adjusted
periodically according to page fault statistics). These pages are divided into
three sets: the working set, the free list and the dirty list. All three are 
mapped by the process's page table, but only the first set is allowed to be 
used by the process. When a page is faulted out, it goes to the free list 
or the dirty list, depending on whether it was modified. Another page
is dropped off the free or dirty list, in FIFO fashion. Dirty pages must
of course be written to disk. 

When a page fault occurs, the page tables are checked to see if the page is 
in the free list or dirty list. If so, the page is taken off that list and 
put in the working set. This is called a 'soft' page fault. If not, we need
to get a page from disk, a 'hard' page fault. A page is chosen at random 
to be taken out of the working set, and put at the head of the free or 
diry list.

If you consider only the traffic to and from disk, this looks a lot like LRU
(least recently used), because pages on free and dirty lists, while chosen at 
random, age in a FIFO before being discarded or written back. In place of the
scanning of the working set for reference bits, we have the soft page faults.

Michael Weaver
Weitek

 
Technical Details
Message-ID: <18219@weitek.WEITEK.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!wuarchive!wugate!uunet!ubvax!weitek!weaver
References: <3332@blake.acs.washington.edu> <261500008@S34.Prime.COM> <249@gp.govt.nz> <2389@auspex.auspex.com> <AGLEW.89Aug29104841@chant.urbana.mcd.mot.com> <2396@auspex.auspex.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!wuarchive!wugate!uunet!ubvax!weitek!weaver
From: weaver@weitek.WEITEK.COM
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Message-ID: <18219@weitek.WEITEK.COM>
Date: 31 Aug 89 16:19:34 GMT
References: <3332@blake.acs.washington.edu> <261500008@S34.Prime.COM> <249@gp.govt.nz> <2389@auspex.auspex.com> <AGLEW.89Aug29104841@chant.urbana.mcd.mot.com> <2396@auspex.auspex.com>
Sender: weaver@weitek.WEITEK.COM
Reply-To: weaver@weitek.UUCP (mike weaver)
Organization: WEITEK Corp. Sunnyvale Ca.
Lines: 33