Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!newcastle.ac.uk!turing!ncrr
From: C.R.Ritson@newcastle.ac.uk (C.R. Ritson)
Newsgroups: comp.sys.encore
Subject: Re: Multimax thrashing
Message-ID: <1990Dec20.124107.19571@newcastle.ac.uk>
Date: 20 Dec 90 12:41:07 GMT
References: <1990Dec3.170300.14750@newcastle.ac.uk> <130064@infocenter.encore.com> <2166@sirius.ucs.adelaide.edu.au>
Sender: news@newcastle.ac.uk
Organization: University of Newcastle upon Tyne, UK, NE1 7RU
Lines: 24

francis@cs.ua.oz.au (Francis Vaughan) writes:

     (in  responce  to  my  complaint about a Multimax running Umax4.3
     R4.1.0 thrashing)...

>I wonder if some of the memory thrashing obseved is due to the problem in
>the memory manager that locks down copy-on-write pages. Any sign of this being
>fixed? Our perception (on our machine anyway) is that this is costing us about
>half the performace of our machine. We are not happy.
>(Machine is 48MB, 4xXPC, EMC & MSC)

This  did  turn out to be the case.  We run X11R4, and before patching
xterm this was costing us 23 our of our 64 Mbytes as COW pages with by
now only one user.  We have a patched xterm that  has  improved  this.
One  problem  is  that  although things are better, I have no idea how
many other utilities are locking down memory in this way?

If  a page has only one user, why can't the COW status can be switched
off?  This would improve things a lot, as there must be many  programs
that  fork  and  exec,  but where the parent has a lot of data that it
does not modify.  Like all the shells perhaps?  I do not know if these
use vfork instead, I presume vfork is not causing similar problems.

Chris Ritson.