Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!tymix!tardis!jms
From: jms@tardis.Tymnet.COM (Joe Smith)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DMA in VM
Summary: Disk buffers are less desireable on good VM implementation.
Message-ID: <839@tardis.Tymnet.COM>
Date: 1 Dec 89 03:50:44 GMT
References: <14059@grebyn.com>
Reply-To: jms@tardis.Tymnet.COM (Joe Smith)
Organization: BT Tymnet, San Jose, CA
Lines: 65

In article <14059@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes:
>	Oh, and it would be a dirty shame if programs weren't able to
>allocate virtual memory for their disk buffers, IMHO. It would make
>virtual memory less useful.

Although it makes it easer for lazy programmers, that would cause more
system overhead.

On a mediocre implementation of VM, the OS simply provides virtual memory
so that programs think they are running in a lot of real memory and cannot
tell that they are paging to the swapping disk.

On a good implementation of VM, the OS provides support so that program can
be fully aware of paging to and from the disk.  In this case, programs do
not allocate virtual memory for disk buffers.  Instead, they allocate virtual
pages to be mapped to disk pages.

Instead of telling the OS to read some blocks from the disk into a buffer
that starts on an arbitrary byte boundary (and may span several pages),
the better programs tell the OS associate a page of disk blocks to a
chunk of virtual memory that starts (and ends) on a page boundary.
If some other task has that disk page already mapped into physical memory,
the OS does not have to re-read those blocks.  It simply changes your task's
page map to point to what has already been read in.

A program that does not co-operate with VM would:
  1) allocate a large disk buffer
  2) open the file
  3) read the entire file into the buffer
  4) search through the buffer, modifying some bytes as needed
  5) write the buffer out to the file
  6) close the file.

But if you have allocate a disk buffer that is bigger that available
physical memory, the system will have to:
  A) write some other portion of virtual memory out to the swapping disk
     to free up a chunk of physical memory
  B) read the next chunk of data in from the file to physical memory
  C) write out this chunk to the swapping disk
  D) repeat steps B and C until the entire buffer has been filled
  E) swap in the code portion of the program that went out in step 1
  F) swap in bits and pieces of the giant buffer as the program accesses it.
  G) reverse steps B and C when the buffer is written back out

On a VM system like TOPS-20 or TYMCOM-X, the steps above would be:
  1) allocate a range of virtual pages to be mapped to the file
  2) open the file and have it mapped read+write into virtual memory
  3) search through virtual memory, modifying some bytes as needed
  4) close the file.

and the OS would:
  A) trap the page fault when the program attempts to access a page not
     currently in memory
  B) write modified pages back to the disk file (since we asked for this)
  C) read the appropriate page in from the disk file.  (no I/O to swap disk)

Summary: A good implementation of VM makes the concept of "disk buffers"
obsolete.  Existing programs still work, but don't get the same performance
as programs that have been rewritten to take advantage of the VM system.

-- 
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com
BT Tymnet Net Tech Serv | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21    | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."