malc@unrvax.unr.edu (Malcolm L. Carlock) (10/18/90)
A few months ago there was some discussion in this group about a bug
in the paging algorithm of the MIPS version of Ultrix. Reports were
that the bug tended with a frequency that varied more or less inversely
with the amount of memory in the machine. Word also was that the bug
seemed to be fairly well-known, but the DEC wasn't moving very fast toward
acknowledging it.
Does anyone know if a fix for this bug is now available? What DEC's
position is on it?
Please email any responses to me at the address below. Our newsfeed
has been acting up lately, and I'm afraid I might miss any responses
that are posted.
Thanks in advance.
Malcolm L. Carlock Internet: malc@unrvax.unr.edu
UUCP: uunet!unrvax!malcgrr@cbmvax.commodore.com (George Robbins) (10/18/90)
In article <4777@tahoe.unr.edu> malc@unrvax.unr.edu (Malcolm L. Carlock) writes: > A few months ago there was some discussion in this group about a bug > in the paging algorithm of the MIPS version of Ultrix. Reports were > that the bug tended with a frequency that varied more or less inversely > with the amount of memory in the machine. Word also was that the bug > seemed to be fairly well-known, but the DEC wasn't moving very fast toward > acknowledging it. I don't know if DEC has every really acknowledged or explained the problem, however a patch was made available for Ultrix 3.1/3.1a that was supposed to have fixed the problem. The patch did not appear appropriate for 3.1c, and I don't know if same problem exists in 3.1c/3.1d. I'd assume that it is fixed in 4.0. Maybe you'll get a response from one of the people who applied the patch. I'd also suggest checking with the support center... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
paul@caen.engin.umich.edu (Paul Killey) (10/29/90)
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