Xref: utzoo comp.unix.wizards:22791 comp.unix.i386:6599 comp.sys.att:9930 Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.unix.wizards,comp.unix.i386,comp.sys.att Subject: Re: Is VHANDFRAC --> VHANDL dynamic? Message-ID: Date: 7 Jul 90 16:45:58 GMT References: <562@oglvee.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 52 In-reply-to: jr@oglvee.UUCP's message of 6 Jul 90 20:35:01 GMT In article <562@oglvee.UUCP> jr@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk