Xref: utzoo comp.unix.wizards:22850 comp.unix.i386:6779 comp.sys.att:9974 Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!uc!cs.umn.edu!dmshq!com50!quest!ssb From: ssb@quest.UUCP (Scott S. Bertilson) Newsgroups: comp.unix.wizards,comp.unix.i386,comp.sys.att Subject: Re: Is VHANDFRAC --> VHANDL dynamic? Message-ID: <10229@quest.UUCP> Date: 11 Jul 90 12:55:44 GMT References: <562@oglvee.UUCP> Followup-To: comp.unix.wizards Organization: Quest Research Inc., Burnsville, MN Lines: 57 > jr@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 "" - it's also worth looking at ""). 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@poincare.geom.umn.edu