Is VHANDFRAC --> VHANDL dynamic?
Scott S. Bertilson
ssb at quest.UUCP
Wed Jul 11 22:55:44 AEST 1990
> 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
More information about the Comp.unix.wizards
mailing list