Is VHANDFRAC --> VHANDL dynamic?

[Scott S. Bertilson]

> jr at oglvee.UUCP (Jim Rosenberg) wrote:
> I have seen paging behavior under AT&T UNIX V.3.2 on a 6386 where the number
> of free memory pages as reported by sar seems to sit forever drastically
> below what I had *thought* was the low-water mark.  This always seems to
> ...
> This sort of implies but doesn't really say that VHANDL is computed at boot
> time and thereafter left alone.  Is this really how it happens?  Can VHANDL
> get recalculated?  How do I find out what the "real" low-water mark is?  How
> ...
> The V.3 paging parameters mystify me.  I get more JUNK in my mail about
> training seminars, but I would *beg* my management to go to a good one-day
> tutorial on V.3 paging parameters.  Help!

  I suppose this is old hat, but since I haven't seen a reply to Jim's
query, I'm posting my reply in hopes that we'll both get barraged
with pages of useful information. :-)

  I've played with this a fair amount under SVR3.2 on Altos machines.
"VHANDL" doesn't change once the system is up.  You can verify this
using "crash":
	crash
	od -d tune 11
(my system has 11 4 byte integers in the structure defined in
"/usr/include/sys/tuneable.h")
  I've also noticed the behavior you described - not necessarily
during heavy paging, but it seems that free memory as listed
by "sar -r" often goes below GPGSLO without causing paging.
I've adjusted the numbers on my system fairly substantially (the
Altos defines these and other values in "/usr/sys/master.d/kernel"):
	VHNDFRAC=12
	GPGSLO=40
	GPGSHI=100
	GPGSMSK=0x0420
	VHANDR=3
	VHANDL=10
	MAXSC=64
	MAXFC=64
Several values draw heavily on previous versions of UNIX
from Altos.  I have looked at SVR2 on a 68020 and XENIX/SVR2 on a 386.
They don't have as complex a paging system, but do have several
parameters in common.
  My changes did seem to improve things, but I still can't figure
out why free pages should go so low.  Perhaps it is because the
pager will only steal pages if they have been unused for VHANDR * 2
seconds (this is mentioned in "<sys/tuneable.h>" - it's also worth
looking at "<sys/getpages.h>").  I suppose a situation like this
either could mean you're running a very large application and/or
that you are short of physical memory for your application mix.
I sure wish someone would write about the design goals of the SVR3
pager and describe how the parameters are supposed to interact.
I hoped at one point to find something in the Bach book, but
that was probably foolish considering that this is a fine
point that is somewhat implementation dependent.
-- 

Scott S. Bertilson   ...uunet!rosevax!rose3!quest!ssb
			scott at poincare.geom.umn.edu