Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!ihnp4!houxm!hou2b!dwc
From: dwc@hou2b.UUCP (D.CHEN)
Newsgroups: net.arch
Subject: re:paging
Message-ID: <833@hou2b.UUCP>
Date: Tue, 16-Sep-86 11:16:57 EDT
Article-I.D.: hou2b.833
Posted: Tue Sep 16 11:16:57 1986
Date-Received: Wed, 17-Sep-86 06:17:29 EDT
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 54

>	Another consideration, is that on at least some virtual
>	memory systems I've worked with, the the system transfers
>	the program over to some sort of paging file, before it
>	starts, which means that you end up reading the whole
>	program in anyway, and writing it out to boot. Does anyone
>	know of a virtual memory system that doesn't work this
>	way?

i think that alot of the minicomputer based operating systems
don't work this way.  it has something to do with the size of
the paging area.  many systems are not configured to have enough
swap or paging space to hold all the programs that may run at once.

also, in order to recoup the overhead in doing the read and write
of the program file (in order to put it contiguously on the paging
file), the program would have to run long enough to make it worthwhile.
at least in the unix environment, this is generally not the case
(you know, build applications using small tools and all that).

one other aspect that i think is interesting is this:  those systems
that attempt to write everything to the paging file first are attempting
to reduce the work to do reads (or page ins...assuming that program
behavior allows them to take advantage of contiguity).  those systems
that do not guarantee contiguity on the paging file are attempting
to reduce work for writes (page outs).  so the choice depends on:

	1) how much more often reads are done than writes
	2) how long process run and memory contention

>	I'm no big fan of virtual memory. It made sense back in the
>	days of timesharing systems with expensive core memories,
>	but now with cheap semiconductor memory RAM disks and big
>	disk caches make more sense.


virtual memory isn't that bad.  there are several advantages that
can be useful when there just isn't enough physical memory.  if
there is, and if the virtual memory scheme is flexible enough,
about all you pay is the cost of page and segment table address
translation.

aside from some semantic differences between files and memory address
space, a virtual memory scheme can provide "large disk caches" if
there is the ability to map files into address spaces.  in fact,
in unix, alot of the structure of the buffer cache and memory management
would be duplicated if we had memory mapped files.

and still being a believer in a weak form of locality of reference,
i feel that the ram used in a ramdisk is better used in main memory
where the o.s. has an opportunity to control its allocation for
higher utilization (there are other factors of course).

danny chen
ihnp4!hou2b!dwc