Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!ogicse!cs.uoregon.edu!ns.uoregon.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: <1991May2.231911.23612@milton.u.washington.edu>
Date: 2 May 91 23:19:11 GMT
References: <12714@dog.ee.lbl.gov> <1991May2.052140.27048@milton.u.washington.edu> <12759@dog.ee.lbl.gov>
Organization: University of Washington, Seattle
Lines: 55

In article <12759@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>
>I presume you mean these three lines:
>
>	if (c->c_type != CTEXT) {
>		if (rp->p_rssize < saferss - rp->p_slptime)
>			return (0);
>	}
>
>Since p_rssize is in units of `core clicks' (512 or 1024 bytes) and
>saferss is 32 and p_slptime is in [0..127] and all of the numbers
>are signed (I checked :-) ), this should only affect processes with
>less than 16 or 32 KB of resident set size, and once they have been
>asleep for 32 seconds, it should not affect them at all (since rssize
>will always be >= 0 and the rhs of the compare will be <= 0).

Yes, that's the place which is OK in BSD but DEC changed p_rssize to
unsigned so it would have worked only until the right side became negative;
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.  But I need
to back off a little here and remind readers that this is what I discovered
happens on Ultrix and the code looks very similar but I haven't experimented
with BSD.

>Anyway, now that I am looking at the hardswap code, I think you are
>right:  the code iterates through the whole proc table (never stops)
>but only accumulates `big' processes if it does not find a `sleeper'
>(something sleeping for > 20 seconds).  Generally there is always at
>least one such, and it takes that one and then starts the whole thing
>over (as you described).  If the paging system has done its job,
>however, this will gain little and after a dozen or so sleepers
>have been swapped out, the `big' process code will fire.

So on our system, the paging system was not doing its job because it was
only paging out what little text it could find between lots of stale data
and we had enough processes in the process table that there were always
enough sleepers to swap out and in at the beginning of the process table
and the results were not pretty.

Chris, I really thank you for taking the time to look this over.  I hope,
as you say, it is already done right in the new code.

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