Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!
wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!bin
From: b...@primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.sys.mips
Subject: vmstat
Message-ID: <854@uakari.primate.wisc.edu>
Date: 9 Oct 89 21:07:29 GMT
Organization: UW-Madison Primate Center
Lines: 10
M/120, RISC/os 4.01:
% vmstat
No vmstat in this release.
When? (Release notes just say "planned for a future release".)
5.0?
Paul DuBois
dub...@primate.wisc.edu
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!
gem.mps.ohio-state.edu!apple!mips!rogerk
From: rog...@mips.COM (Roger B.A. Klorese)
Newsgroups: comp.sys.mips
Subject: Re: vmstat
Message-ID: <29174@servitude.mips.COM>
Date: 10 Oct 89 02:27:23 GMT
References: <854@uakari.primate.wisc.edu>
Reply-To: rog...@mips.COM (Roger B.A. Klorese)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 27
In article <8...@uakari.primate.wisc.edu> b...@primate.wisc.edu (Brain in Neutral)
writes:
>M/120, RISC/os 4.01:
>
> % vmstat
> No vmstat in this release.
>
>When? (Release notes just say "planned for a future release".)
>5.0?
It will probably *not* be completed for the next full-product-line release
(which, as of this date, probably will *not* be called 5.0, but will have
any features you may have been told to expect in that release). Our new
VM system is sufficiently closer to BSD's as to make the task somewhat
simpler, but it's still not identical, and we don't want to make a half
attempt at it.
For now, "vsar -upwbcr" should supply sufficiently similar info.
>
>Paul DuBois
>dub...@primate.wisc.edu
--
ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939
928 E. Arques Ave. Sunnyvale, CA 94086 rog...@mips.COM
{ames,decwrl,pyramid}!mips!rogerk
"I want to live where it's always Saturday." -- Guadalcanal Diary
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!
swrinde!ucsd!ames!sgi!...@patton.sgi.com
From: j...@patton.sgi.com (Jim Barton)
Newsgroups: comp.sys.mips
Subject: Re: vmstat
Message-ID: <42752@sgi.sgi.com>
Date: 10 Oct 89 15:07:36 GMT
References: <854@uakari.primate.wisc.edu> <29174@servitude.mips.COM>
Sender: j...@patton.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 25
In article <29...@servitude.mips.COM>, rog...@mips.COM (Roger B.A. Klorese) writes:
> In article <8...@uakari.primate.wisc.edu> b...@primate.wisc.edu (Brain in Neutral)
writes:
...
> ... Our new
> VM system is sufficiently closer to BSD's as to make the task somewhat
> simpler, but it's still not identical, and we don't want to make a half
> attempt at it.
...
> ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939
> {ames,decwrl,pyramid}!mips!rogerk
Interesting. Sun, AT&T, SGI, etc., are all moving away from BSD-like VM
systems to single-level store based systems with region/segment management
(SunOS 4.0, System V.4, IRIX 3.3). The Mach VM system is a research system
with region management as well, although single-level store isn't
quite there yet.
This seems like a big step backwards in terms of VM management. Can this
really be true?
-- Jim Barton
Silicon Graphics Computer Systems "UNIX: Live Free Or Die!"
j...@sgi.sgi.com, sgi!...@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!mips!...@mips.com
From: w...@mips.com (William J. Earl)
Newsgroups: comp.sys.mips
Subject: Re: vmstat
Message-ID: <29501@igate.mips.COM>
Date: 15 Oct 89 05:38:14 GMT
References: <854@uakari.primate.wisc.edu> <29174@servitude.mips.COM> <42752@sgi.sgi.com>
Sender: w...@mips.COM
Reply-To: w...@mips.com (William J. Earl)
Organization: MIPS Computer Systems Inc.
Lines: 55
In-reply-to: jmb@patton.sgi.com (Jim Barton)
In article <42...@sgi.sgi.com>, jmb@patton (Jim Barton) writes:
> In article <29...@servitude.mips.COM>, rog...@mips.COM (Roger B.A. Klorese) writes:
> > In article <8...@uakari.primate.wisc.edu> b...@primate.wisc.edu (Brain in Neutral)
writes:
> > ... Our new
> > VM system is sufficiently closer to BSD's as to make the task somewhat
> > simpler, but it's still not identical, and we don't want to make a half
> > attempt at it.
>..
> Interesting. Sun, AT&T, SGI, etc., are all moving away from BSD-like VM
> systems to single-level store based systems with region/segment management
> (SunOS 4.0, System V.4, IRIX 3.3). The Mach VM system is a research system
> with region management as well, although single-level store isn't
> quite there yet.
>
> This seems like a big step backwards in terms of VM management. Can this
> really be true?
The RISC/os 4.50 VM system is closer to the 4.3 BSD VM system
only in that it steals pages using a clock algorithm which scans the
physical page frame table at a variable rate, adjusted to be fast
enough to provide free pages at roughly the rate they are being
consumed (assuming enough swap partitions have been configured to
provide enough disk bandwidth to clean pages faster than pages are
being dirtied). (Previous RISC/os releases used System V Release 3
page stealing, which walked the region table.) The other important
change is that region locks are generally not held across sleep()'s,
so that only pages which have been locked in main memory are protected
from being stolen.
RISC/os has regions, as in System V.3 and System V.4, including
both shared and private regions. The VM data structures are roughly
comparable to those in SunOS 4.0 or System V.4, although some are more
compact. RISC/os does not yet share pages between the disk buffer
cache and the VM page cache, although one cache may grow in size at
the expense of the other.
I don't see, however, in what way a 4.3 BSD VM system is a
"step backward" from, say, a SunOS 4.0 VM system, other than that the
disk buffer cache and the VM page cache are not integrated. 4.3 BSD
lacks general regions, but it does have a special case of them.
(That is, each process has a stack and a data region, and generally
shares one text region; the locations where the regions are mapped
into the process's virtual address space are implicit instead of
explicit.) 4.3 BSD does use a clock algorithm for stealing pages,
and it does have thrashing control.
This is not to say that such a VM system is "advanced". It is
actually fairly primitive, in that it lacks working set swapping
(when thrashing is being controlled by reducing the multiprogramming
set), lacks any notion of relative priority of various types of
paging and file system I/O's, and lacks any notion of process classes.
(The latter, which are starting to appear for CPU scheduling, allow
one to say things like, "keep the working sets for the X server and
the window manager in memory." This is important if one wants to
implement a small system with consistent interactive response.)