Xref: utzoo comp.unix.ultrix:5097 comp.sys.dec:4360
Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!paul
From: paul@caen.engin.umich.edu (Paul Killey)
Newsgroups: comp.unix.ultrix,comp.sys.dec
Subject: Re: Fix yet for paging algorithm in MIPS Ultrix?
Message-ID: <1990Oct29.001219.3292@engin.umich.edu>
Date: 29 Oct 90 00:12:19 GMT
References: <4777@tahoe.unr.edu> <15232@cbmvax.commodore.com>
Sender: news@engin.umich.edu (CAEN Netnews)
Organization: University of Michigan Engineering, Ann Arbor
Lines: 31

We saw a problem running some (but not all) large jobs on dec stations
with 8M of ram.  This under 3.1d, but also seems to be the case with
3.1.

We got a patch tape (new versions of vm_text.o and vm_swap.o) and tried
it out.  It made things better.

The results:

On a 12M machine, the program (meta language, sml) ran using 3% of the
cpu, was swapped 32 times, and had nearly 172,000 page faults (this
from time).

With the fix, it used 13% of the cpu, and "only" was swapped 7 times
and had just under 32,000 page faults.

On a machine with 32M of ram, and without the fix applied, it used 55%
of the cpu, and had zero swaps and 426 page faults.

On the 32M machine, it runs in less than 4 minutes.  On the 8M
machines, it takes over 20 minutes.

Size on the program reports:

text    data    bss     dec     hex
2379776 1122304 0       3502080 357000

Sure, it's a jumbo and you can expect some paging overhead, but as much
as we see is a little extreme.

--paul