Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rutgers!rochester!pt.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: bug in Mach 2.5 in copy-on-write?
Message-ID: <saijbmS00hsQERS10z@cs.cmu.edu>
Date: 4 Aug 90 16:38:10 GMT
References: <10871@spool.cs.wisc.edu>,
	<10107@pt.cs.cmu.edu>
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 25
In-Reply-To: <10107@pt.cs.cmu.edu>

> Excerpts from netnews.comp.os.mach: 4-Aug-90 Re: bug in Mach 2.5 in
> copy.. Avadis Tevanian@wb1.cs.c (661)

> In article <10871@spool.cs.wisc.edu> shekita@provolone.cs.wisc.edu (E
> Shekita) writes:
> >
> >for (i = 0; i < 100; i++) {
> ....
> >    source_page[0] = 'a'; 
> ....
> >    vm_read(task_self(), (vm_address_t) source_page, vm_page_size, 
> >	   (vm_address_t*) &destination_page, &readCount);
> ....
> >    destination_page[0] = 'b';

> No bug here... if you remember that both the source and destination pages
> are set to copy-on-write then you realize that each time you touch the 
> source page after the vm_read you generate another COW fault.  The result
> you get of 199 is exactly as expected.

Well, it isn't a bug, because that is how the VM implementation is
designed to work, but there is a point to be made.  The COW faults on
the source are unnecessary, and a better implementation would avoid them.

Rich