Performance Tuning Ultrix 4.1

[Corey Satten]

In article <12714 at dog.ee.lbl.gov> torek at elf.ee.lbl.gov (Chris Torek) writes:
>In article <1991Apr30.160331.16215 at milton.u.washington.edu>
>corey at milton.u.washington.edu (Corey Satten) writes:
>>(This is cross-posted to unix-wizards because it may also apply to 4.3BSD)
>
>Just a quick note:  It seems unlikely to, as the code being changed is
>almost completely different in 4.3BSD.  In particular, the swapout code
>picks the five largest processes, not the `first' set of processes that
>will satisfy the immediate demands.

Oh dear, I can't believe I'm about to take issue with Chris Torek.  This
is indeed a rare day.  I hope I don't blow it.

Chris, I find almost identical code in 4.3BSD (tahoe I think).  In file
vm_page.c the lines which prevent data from paging are almost identical
(but without DEC's SMP locking).  In file vm_sched.c the code near the
comment about swapping out deadwood is almost identical with Ultrix and
on our system, that was the code which was doing almost all of the
swapping (though possibly because I elevated the values of lotsfree and
desfree and scan rate to improve performance in round 1).  I think you
are talking about the "hardwsap" code (when desperate == 1), which on
our system, turned out to rarely execute.  In any case, even if
hardswap does happen, it still looks like it doesn't use the largest 5
processes (as the comment would indicate) if there are any processes
which have been sleeping longer than maxslp (20 seconds), I think it
uses the one closest to the beginning of the process table which has
been sleeping the longest.  I think longest maxes out at 127 seconds so
with our process mix, that means it would usually swap the first
few processes which have been sleeping at least 127 seconds.

Anyway, as I said, I haven't measured a BSD system and I didn't study
hardswap as closely as the other since it almost never happened on our
system, so I only say it may apply because the code looks to me very
similar to the Ultrix code I have become rather familiar with.
Furthermore, now that we are paging out data, we aren't swapping
processes with RSS>0 at all so I think the paging part of the fix may
be more important than the swapping part anyway.

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