🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2166

Re: Memory utilization & inter-process contention

#2166
From: Gary Bridgewater
Date: Sat, 09 Sep 1989 09:04
38 lines
2700 bytes
In article <45344@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>In article <2089@uceng.UC.EDU> dmocsny@uceng.UC.EDU (daniel mocsny) writes:
>>In article <278@baird.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:
>>> A VM system general enough to perform well for most potential users and
>>> their applications on most potential hardware platforms is asking a lot.
>This gets back to fundamental laws.  One of them is "special purpose
>is always cheaper than general purpose [to do the same specific job]".

I think it goes deeper than that. People want to buy the cheapest box that
will do their job. They want to pull it out of the box, plug it in and
have it satisfy their deepest desires from the git go.

A reasonable method of solving the paging problem would be to divorce the
paging functionality from the policy decisions. Then you document the
interface to the policy modules, provide a default and let the end users
customize the thing as much as they want. All the necessary information
would be made available via tables/calls to allow the finest micro-tuning.
Note that this is (intended to be) a far cry from buying the sources, hiring
a guru and letting him/her fool around for six months.

The problem is that this is complicated and may, horrors, require reading the
manual (that shiny thing in the shrink wrap package in the back of your file
drawer, remember?). In any case, I still don't expect a hue and cry from the
user community for this. Memory is cheaper than gurus' salaries over the
same time frame. I don't mean to imply that customers are stupid, they just
aren't (usually)  computer literate and they don't want to be.

I don't think you can have the perfect (to some degree) generic algorithm.
The variables multiply too fast and behavior differences are nearly
infinite. And, don't forget that the purpose of VM is to save money, not
time. If you want real memory performance then get real memory. If you
want to emulate real memory at a cost of V/R then get VM. TANSTAAFL or
TANSTAFM.
-- 
Gary Bridgewater, Data General Corp., Sunnyvale Ca.
gary@sv4.ceo.sv.dg.com or 
{amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary
No good deed goes unpunished.
Technical Details
Message-ID: <1097@svx.SV.DG.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!oliveb!amdahl!dgcad!gary
References: <1114@aber-cs.UUCP> <278@baird.cs.strath.ac.uk> <2089@uceng.UC.EDU> <45344@bbn.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!oliveb!amdahl!dgcad!gary
From: gary@dgcad.SV.DG.COM (Gary Bridgewater)
Newsgroups: comp.arch
Subject: Re: Memory utilization & inter-process contention
Message-ID: <1097@svx.SV.DG.COM>
Date: 9 Sep 89 09:04:54 GMT
References: <1114@aber-cs.UUCP> <278@baird.cs.strath.ac.uk> <2089@uceng.UC.EDU> <45344@bbn.COM>
Reply-To: gary@svx.SV.DG.COM ()
Organization: Data General SDD, Sunnyvale, CA
Lines: 36