[Info-vax] Raxco VMS Tuning Seminar Notes

[jls]

On 3 Nov 2010 08:47:09 -0600, koehler at eisner.nospam.encompasserve.org
(Bob Koehler) wrote:

>In article <2bae0454-f09a-45d1-808a-a8fd7e3ffb51 at t13g2000yqm.googlegroups.com>, Neil Rieck <n.rieck at sympatico.ca> writes:
>> On Nov 1, 12:10=A0pm, jls <notva... at yahoo.com> wrote:
>> 
>>>
>>> Again with the "always". =A0The drawbacks with this memory management
>>> technique are:
>>> =A0 =A0 =A0 =A0 1. it uses CPU to constantly manage memory, thus taking
>>> available CPU from users =A0This is a trade-off that is not adequately
>>> understood by many people.
>>> =A0 =A0 =A0 =A0 2. it only takes memory from ACTIVE users, not idle users=
>> .
>>> This forces the active users to pagefault much more to get work done.
>>>
>> 
>> How could the SWAPPER not trim idle users? They would be faulting at a
>> rate of less than PFRATL (if not zero). As I under stand this, you
>> would want to trim the working set to a smaller size then swap out
>> that smaller set. Not all trimmed pages would ever be faulted back in
>> (based upon the theory that you run 10% of the code 90% of the time)
>
>   When PFRATL was non-0, it trimmed idle processes on my systems.  Only
>   running processes got page faults at any non-0 rate, and tended to
>   grow rather than shrink, because of PFRATH.  By just a little
>   gentle tuning I got some RAM starved VAXstations running fine for
>   interactive users, with the background processes for DECnet et. al.
>   just a swap-in away on the rare occaision when we needed them.
>

PFRATL does not trim idle processes.  It is a quantum-driven memory
management technique and idle processes do not reach quantum end.