Is VHANDFRAC --> VHANDL dynamic?

[Piercarlo Grandi]

In article <562 at oglvee.UUCP> jr at oglvee.UUCP (Jim Rosenberg) writes:

   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?

>From what I understand VHANDL *is* a constant.

   How do I find out what the "real" low-water mark is?  How else can I
   explain a quiet system just sitting there with far fewer free pages
   than the low-water mark?

You probably are thinking of the wrong definition of 'free' page. In
theory in a machine where the total of process virtual memory sizes is
larger than the physical memory available, there should not ever be any
really free pages. What happens is that the pger will make a distinction
between active and *inactive* pages; and will put the *inactive* pages
on the to-be-free list, ready to be reused, but it will not actually
clean them out and reuse them unless there is demand for actually-free
memory.

   The V.3 paging parameters mystify me.  I get more JUNK in my mail
   about training seminars,

What about reading the book "The design of the UNIX operating system" by
Bach, Prentice-Hall, ISBN 0-13-201757-1, that describes in some detail
the algorithms used by the System V pager? I have a copy before me just
now, and it has Chapter 9 "Memory management policies" which is quite
explicit, e.g. subsection 9.2.2, "The Page-Stealer Process", page 294.
It might also help to read the article on the 386 port that appears in
"Unix Papers" published by SAMS.

   but I would *beg* my management to go to a good one-day tutorial on
   V.3 paging parameters.  Help!

Unfortunately the System V paging and swapping policies *stink* as Bach
regretfully hints, and the only advice you will get from AT&T is to buy
more memory so that they will never get exercised. Hope that S5.4 is not
that bad -- after all it is largely influenced by SunOS, and Sun
recently corrected at least one of the most glaring mistakes they had
made in the SunOS paging/swapping algorithms...

Probably helping Toshiba and Hitachi clear the memory chip glut is the
easiest way out. This offends my aestethics, but hey, USA operating
system designers that care/know about virtual memory management are
probably rarer than Japanese VLSI process engineers :-).

--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk