You could do worse than Mach ports

[David Schultz]

On Fri, Jul 18, 2003, Matthew Dillon wrote:
> 
> :I don't see why the COW scheme would be necessary.  If a user
> :process writes to a page undergoing I/O, it deserves whatever it
> :gets.  This can happen, for instance, if write(2) is invoked on a
> :buffer from one thread while another thread writes to the buffer.
> :The race is inherent, so protecting the pages and informing the VM
> :system that they are COW can only decrease the size of the window,
> :not eliminate it.  There are similar underlying assumptions for
> :AIO and FreeBSD's pipe implementation.
> 
>     Most writes are buffered through the buffer cache and either delayed
>     or asynchronized, so it is fairly easy to write out a file and then
>     mmap() it and wind up getting stalled because the original writes
>     are still in progress.

Aah, so the concern is what happens after the write(2) call
returns because you're doing the I/O asynchronously.  (That should
have been obvious to me, but I was thrown off by the talk of DMA.)
So yes, COWing the page sounds like the right way to go.

>     Another big problem is with paging... if
>     the pageout daemon decides to write out a page which you then attempt
>     to modify, your process will stall for no good reason.

In this case, you can get away without the COW.  You just allow
the race to occur, and in the (relatively unlikely) event that the
page gets modified while you're trying to page it out, you notice
the dirty bit after the I/O has completed and you pretend that you
never wrote out the page at all.

>     One also can hit serious with write stalls with directories,
>     inodes, bitmap nodes, and so forth.

Here I would expect softupdates' explicit roll forward/roll back
mechanism to outperform any VM tricks you could do.  You should be
able to queue up dependencies without any stalls at all even while
I/O is in progress.