From: Jim Choate <ravage@ssz.com>
Date: Tue, 3 Feb 1998 09:49:58 +0800
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: VMM question - reply (fwd)
Message-ID: <199802030146.TAA30693@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text



Forwarded message:

> Date: Mon, 02 Feb 1998 01:39:47 -0600
> From: Lenny Blumberg <lenny@bga.com>
> Subject: VMM question - reply

> Hmmmm.....
>       I would imagine that the OS would keep a disk map in memory and
> mark it with a flag to indicate if it's been paged into memory.

This is a function of the "Look Aside Buffer" and the actual operation is a
bit more complicated. The vmm must keep up with which processes have it
mapped, where in their indipendant memory maps it shows up at, what the
status is in each of those maps, whether it's sharable or not (though the
Linux vmm doesn't seem to do any write locking), and probably some functions
that I've missed.

> At
> that point, instead of updating the disk drive - It looks up the page in
> memory and updates that copy.

There are two ways to do this in general...

Write-through: means the vmm goes ahead and not only updates the vmm copy
               but the copy on the drive. Note that this may or may not
               actualy update other copies if a process has one that isn't
               sharable (ie has its own private copy). This has a lot of
               over-head in that there is lots of i/o.

Write-back: means that the data in the individual pages doesn't get written
            to the drive until the page is either swapped out of active
            memory (and written to swap) or is closed. This is a form of
            'lazy propogation'. Again, this doesn't address how other
            processes may have their images effected.

>   The only problem is that at that point,
> you're now running into a mess of lock problems that carry their own
> overhead.

One easy way, at least on a Unix machine, is to keep the system clock setting
when the page is created. Then close them in chronological sequence. This
obviously has it's problems. The first person to open isn't guaranteed to be
the first person done. Another method would be to select via a PRNG the
'first' process to update the page. Then each following would take their
turn according to the spin of the wheel. This leaves us with two options,
as each process closes it only writes the changes that it has made; which
could overwrite the previous user if they edited the same part of the file.
The alternative would be to force each user to create a different file with
some filename convention to differentiate them. Then leave it up to some
unknown method to arbitrate the file propogations at that point by some
'compare and share' method perhaps.

>      Another alternative would be to track the disk map and force a
> write for a page that is pending a read.

How do you know ahead of a read that a process is going to read that page?
Or are you saying that before another process can open a file we force the
first process to go ahead and write its changes? What happens once two or
more have the page mapped and begin editing? How do you propose to manage
the file closure writes that will occur?


    ____________________________________________________________________
   |                                                                    |
   |       The most powerful passion in life is not love or hate,       |
   |       but the desire to edit somebody elses words.                 |
   |                                                                    |
   |                                  Sign in Ed Barsis' office         |
   |                                                                    | 
   |            _____                             The Armadillo Group   |
   |         ,::////;::-.                           Austin, Tx. USA     |
   |        /:'///// ``::>/|/                     http://www.ssz.com/   |
   |      .',  ||||    `/( e\                                           |
   |  -====~~mm-'`-```-mm --'-                         Jim Choate       |
   |                                                 ravage@ssz.com     |
   |                                                  512-451-7087      |
   |____________________________________________________________________|