Is VHANDFRAC --> VHANDL dynamic?

[Jim Rosenberg]

In <PCG.90Jul7174558 at odin.cs.aber.ac.uk> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:


>In article <562 at oglvee.UUCP> jr at 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 <disclaimer.h>      --cgh!amanue!oglvee!jr
Oglevee Computer Systems                                        /      /
151 Oglevee Lane, Connellsville, PA 15425                    pitt!  ditka!
INTERNET:  cgh!amanue!oglvee!jr at dsi.com                      /      /
-- 
Jim Rosenberg             #include <disclaimer.h>      --cgh!amanue!oglvee!jr
Oglevee Computer Systems                                        /      /
151 Oglevee Lane, Connellsville, PA 15425                    pitt!  ditka!
INTERNET:  cgh!amanue!oglvee!jr at dsi.com                      /      /