Xref: utzoo comp.unix.wizards:22849 comp.unix.i386:6774 comp.sys.att:9972 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!cgh!amanue!oglvee!jr From: jr@oglvee.UUCP (Jim Rosenberg) Newsgroups: comp.unix.wizards,comp.unix.i386,comp.sys.att Subject: Re: Is VHANDFRAC --> VHANDL dynamic? Message-ID: <565@oglvee.UUCP> Date: 11 Jul 90 22:18:51 GMT References: <562@oglvee.UUCP> Organization: Oglevee Computer Systems, Connellsville, Pa Lines: 63 In pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <562@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes: > 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. Hello? Let me see if I understand this. The page-stealing demon will not *really* move a page out to swap space unless a process actually *asks* for more memory. Ah, but a process asking for more memory might *not* allow sleep, and since the page-stealing daemon is asynchronous there's no guarantee exactly when it will run. So I could just sit there with free pages as shown by sar well below what I think the low-water mark should be, and then if a burst of activity (lots of forks, say) happens very rapidly, free memory could fall to 0 before the paging daemon could catch up. Now if this is how it works, I have to say *WHY*, for crying out loud! Why doesn't the page-stealing daemon *steal pages* when the number of free pages falls below the low-water mark??? Were they worried about thrashing? >Unfortunately the System V paging and swapping policies *stink* as Bach >regretfully hints, You can say that again! BTW I have read Bach. I actually reread the paging stuff when I began having these problems, and found no enlightenment (other than the obvious mantra, "Buy Them Chips! Buy Them Chips! ..." I guess I should go read it again. I've also observed what appears to be a kind of *deadlock*. I have a batch database job running -- *extremely* disk intensive. All of a sudden the hard disk light goes out, even though the job has not finished. The system is just "stuck"! If I toggle to another virtual terminal with a getty running on it and press RETURN, woila, the batch job comes suddenly unstuck. Most disconcerting. At home I have an AT&T 3b1. It has a curious bastardized version of UNIX: SVr0 with a patchwork of V.2 stuff and a few BSD utilities and Convergent's various enhancements. I believe its VM system is competely Convergent homebrew. The system has 2M, and I have *NEVER* seen any of the kinds of problems I see all the time with V.3.2. The machine is quite slow by today's standards, but it sure has a *solid* feel. "Fragile" is more than kind as a description of the V.3 paging system. I sure hope the new VM system in V.4 is solid, what we have now is a mess. -- Jim Rosenberg #include --cgh!amanue!oglvee!jr Oglevee Computer Systems / / 151 Oglevee Lane, Connellsville, PA 15425 pitt! ditka! INTERNET: cgh!amanue!oglvee!jr@dsi.com / / -- Jim Rosenberg #include --cgh!amanue!oglvee!jr Oglevee Computer Systems / / 151 Oglevee Lane, Connellsville, PA 15425 pitt! ditka! INTERNET: cgh!amanue!oglvee!jr@dsi.com / /