Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Sizes of processes under sr10.2 and sr10.3
Message-ID: <4fa7dbee.1bc5b@pisa.ifs.umich.edu>
Date: 6 Feb 91 17:48:55 GMT
References: <1082@eba.eb.ele.tue.nl> <HANCHE.91Feb5184146@hufsa.imf.unit.no>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 14

In article <HANCHE.91Feb5184146@hufsa.imf.unit.no>, hanche@imf.unit.no (Harald Hanche-Olsen) writes:

  The sizes given are so impossibly huge I have never trusted them.
  Therefore, by implication, I have never trusted the ps sizes for the
  m68k processes either.  Maybe I am being unfair.  If someone who knows
  could post the appropriate conversion factors I would be grateful.

The sizes reported by ps when there is a dn10000 involved are often a factor
of 4 too small or too large.  This is because of the change in page size to
4k and inadequate testing.  I haven't tried all the combinations to know
exactly what fails, and it seems to have changed at sr10.3.  Sizes reported
by a m68k for m68k processes are correct.

Anyone care to submit an APR?