Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!milton!corey
From: corey@milton.u.washington.edu (Corey Satten)
Newsgroups: comp.unix.wizards
Subject: Re: Performance Tuning Ultrix 4.1
Keywords: paging swapping fast large load BSD
Message-ID: <1991May7.160630.8055@milton.u.washington.edu>
Date: 7 May 91 16:06:30 GMT
References: <12759@dog.ee.lbl.gov> <1991May2.231911.23612@milton.u.washington.edu> <12792@dog.ee.lbl.gov>
Organization: University of Washington, Seattle
Lines: 41

In article <12792@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>In article <1991May2.231911.23612@milton.u.washington.edu>
>corey@milton.u.washington.edu (Corey Satten) writes:
>>however I believe that code never executed on Ultrix or BSD because of
>>the code a few lines before (BSD code fragment):
>>
>>		if ((rp->p_flag & (SSEQL|SUANOM)) == 0 &&
>>		    rp->p_rssize <= rp->p_maxrss)
>>			return (0);
>>
>>which the front hand does for valid pages.  I think this means that unless
>>the process has executed a vadvise() to warn of sequential or anomalous
>>paging behavior, the front hand never invalidates data pages.
>
>Not in the old BSD kernel.  The code path is, for the front hand (on
>the VAX):

Chris, I stand corrected for both BSD *and* for Ultrix.  The fragment where
I force all processes to behave as if SEQL or SUANOM was set is (as you
point out) not required to get data pages to page out -- so on Ultrix, only
the signed comparison fix is really required in vm_page.c.  However...

On our Ultrix system, since I have the SUANOM test anded with a global I
can poke while the system is running, I can experiment with turning it on
and off.  I find that without my (technically unnecessary) "fix", our
system can't free enough pages to keep from swapping continuously unless
the scan rate is increased very substantially, and on one of our smaller,
more memory starved systems, the highest scan rate achievable (by poking
fastscan=1 and slowscan=2) is insufficient.  I'm still unsure exactly how
to interpret this, (especially in light of the fact that the number of
dirty pages written to disk is limited to a rather small number per second)
but now that I've experimentally confirmed this, I did want to correct my
earlier posting before everyone forgets what we're talking about.

Thanks again for taking the time to look this over with me.

--------
Corey Satten, corey@cac.washington.edu
Networks and Distributed Computing
University of Washington
(206)543-5611